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FOREWORD 

(U)  This  is  Edition  1,  ATCCIS  Working  Paper  7L,  prepared  for  the  Office  of  the 
Director  of  Information  Systems  for  Command,  Control,  Communications,  and  Computers 
(ODISC4),  Headquarters,  Department  of  the  Army,  in  support  of  the  SHAPE-sponsored 
Army  Tactical  Command  and  Control  Information  System  (ATCCIS)  Phase  II  study  effort. 
The  contents  of  this  document1  were  developed  and  agreed  to  in  the  international  ATCCIS 
forum  and,  consequently,  were  not  subject  to  the  normal  EDA  technical  review  process. 
SHAPE  has  distributed  ATCCIS  Working  Paper  7L  to  those  NATO  nations  and  agencies 
that  have  expressed  an  interest  in  the  ATCCIS  study. 

(U)  Background  information  relating  to  the  overall  ATCCIS  effort  is  contained  in 
the  Preface  of  this  Working  Paper.  It  should  be  noted  that  Oxford  English  spelling 
conventions  are  used  throughout  the  paper  in  accordance  with  standing  NATO  guidelines. 
Additionally,  emerging  international  and  NATO  technical  terminology  is  used  throughout 
the  paper.  Other  ATCCIS  working  papers  will  be  using  this  terminology  in  future  editions. 

(U)  ODISC4  provides  the  U.S.  delegate  to  the  ATCCIS  PWG,  which  consists  of 
militai7,  technical,  and  analytical  representatives  from  France,  Germany,  the  United 
Kingdom,  the  United  States,  SHAPE,  SHAPE  Technical  Centre,  and  the  Allied  Forces 
Central  Europe  (AFCENT).  The  ATCCIS  Steering  Group  provides  overall  direction  and 
approval  of  the  ATCCIS  PWG  work  effort  and  includes  representatives  from  the  PWG 
nations  and  commands,  plus  Belgium,  Canada,  and  the  Netherlands,  with  additional 
representation  (observers)  from  the  Allied  Data  Systems  Interoperability  Agency  (ADSIA), 
the  NATO  Communications  and  Information  Systems  Agency  (NACISA),  and  the  Tri- 
Service  Group  for  Communications  Electronic  Equipment  (TSGCEE).  The  Command  and 
Control  Division,  U.S.  Army  Combined  Arms  Combat  Development  Activity,  provides 
military  expertise;  the  U.S.  Army  Communications-Electronics  Command  and  IDA  provide 
technical  expertise,  with  additional  support  provided  by  the  National  Institute  for  Science 
and  Technology  (NIST);  and  IDA  provides  analytical  expertise  in  support  of  the  U.S. 


1  (U)  This  document  was  prepared  in  response  to  a  request  from  the  Office  of  the  Assistant  Secretary  of 
Defense  (C3I),  Theater  and  Tactical  Command,  Control,  and  Communications  under  Contract  MDA903- 
84-C-0031,  Task  Order  T-J 1-246,  UNCLASSIFIED. 
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contributions  to  the  overall  ATCCIS  effort.  Further  details  concerning  the  ATCCIS  Phase 
II  study  can  be  found  in  the  ATCCIS  Work  Plan.2 

(U)  This  paper  should  be  of  primary  interest  to  those  Commands  and  Agencies 
whose  focus  is  on  the  technical  aspects  of  longer-term  command  and  control  requirements. 
Edition  1  of  ATCCIS  Working  Paper  7L  was  reviewed  by  a  panel  of  field-grade  officers 
and  senior  scientists  representing  SHAPE,  AFCENT,  France,  Germany,  the  United 
Kingdom,  and  the  United  States  prior  to  its  distribution  by  SHAPE.  Comments  from 
NATO  and  National  Commands  and  Agencies  have  been  solicited  and  will  be  incorporated 
into  a  final  edition  scheduled  for  later  publication. 


2  (U)  ATCCIS  Phase  II  Work  Plan,  Edition  2,  [DA  Memorandum  Report  M-263,  September  1986, 
UNCLASSIFIED. 
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PREFACE 


1.  (U)  In  1978,  NATO's  Long-Term  Defense  Plan  (LTDP)  Task  Force  on 
Command  and  Control  (C2)  recommended  that  an  analysis  be  undertaken  to  determine  if 
the  future  tactical  Automatic  Data  Processing  (ADP)  requirements  of  the  nations,  including 
that  of  interoperability,  could  be  obtained  at  a  significantly  reduced  cost  when  compared 
with  the  approach  that  had  been  adopted  in  the  past.  The  Task  Force  also  recommended 
that  the  analysis  should  determine  whether  tactical  ADP  systems  could  be  developed 
according  to  technical  standards  prescribed  by  NATO  and  agreed  upon  by  the  nations. 

2.  (U)  In  early  1980  the  then  Deputy  Supreme  Allied  Commander  Europe  initiated 
a  study  to  investigate  the  possibilities  of  implementing  the  Task  Force’s  recommendations. 
Three  nations,  those  with  experience  in  fielding  automated  tactical  command  and  control 
information  systems,  participated  in  Phase  I  of  the  study,  with  Supreme  Headquarters 
Allied  Powers  Europe  (SHAPE)  as  leader  and  coordinator.  The  study  group  reported,  at 
the  end  of  Phase  I,  that  the  nations  could  increase  interoperability  and  potentially  reduce 
costs  by  using  a  common  development  approach.  It  was  also  recommended  that  Phase  II, 
the  definition  of  an  operational  and  technical  concept  and  an  analysis  of  the  likely  impact  of 
a  common  Central  Region  (CR)  (tactical)  command  and  control  information  system,  should 
be  initiated. 

3.  (U)  The  ATCCIS  study,  under  the  direction  of  a  steering  group  chaired  by 
SHAPE  and  consisting  of  representatives  from  the  CR  nations  and  Allied  Forces  Central 
Europe  (AFCENT),  was  established  in  1984.  Concurrently,  a  permanent  working  group 
(PWG)  was  formed  which  consists  of  military,  technical,  and  analytical  representatives 
from  France,  Germany,  the  United  Kingdom,  the  United  States,  SHAPE  and  AFCENT, 
and  technical  support  from  SHAPE  Technical  Centre  (STC)  to  progress  the  Phase  II  effort. 
The  Phase  II  study  effort  commenced  in  January  1985. 
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ATCCIS  Working  Paper  7L 


OPERATIONAL  AND  PROCEDURAL  REQUIREMENTS  FOR 
DATA  MANAGEMENT  AND  STANDARDIZATION1  (U) 

I.  INTRODUCTION 

1.1  Derivation 

(U)  This  working  paper  has  been  produced  in  support  of  Task  4-B-4  [Ref.  1]  of 
the  SHAPE-sponsored  ATCCIS  study  for  a  tactical  command  and  control  (C2)  system 
concept  for  the  year  2000  and  beyond. 

(U)  The  critical  need  for  NATO  data  management  standardization  has  been  clearly 
identified  by  both  the  Allied  Data  Systems  Interoperability  Agency  (ADSIA)  [Ref.  3]  and 
SHAPE  [Ref.  4],  SHAPE  Technical  Centre  (STC)  has  developed  a  general  approach  and 
has  recommended  standardizing  data  management  methodologies  [Ref.  5],  but  data 
management  standards  in  several  areas  need  to  be  developed  for  uses  throughout  NATO, 
including  ATCCIS. 

(U)  Data  element  standardization2  supports  the  sharing  of  information  and  data 
through  uniform  data  representation,  consistent  interpretation,  and  common  understanding. 
Data  element  standardization  is  necessary  to  define  and  implement  Information  Exchange 
Requirements  (IERs).  Specific  objectives  of  data  element  standardization  are  to: 

a.  Ensure  that  data  are  treated  as  a  Command  and  Control  Information  System 
(CCIS)-wide  resource  to  be  shared  to  facilitate  the  coordination,  control,  and 
management  of  IERs 

b .  Reduce  the  cost  of  managing  data  by  eliminating  duplication  and  redundancy 


1  (U)  Reference  for  spellings  in  ATCCIS  is  the  Oxford  English  Dictionary,  Oxford  University  Press, 
Oxford,  1971  (21st  Printing,  1981). 

2  (U)  Note:  Data  element  standardization  specifies  the  definition  and  representation  of  data  elements,  but 
in  no  way  specifies  which  data  elements  "should  be”  parts  of  IERs.  Data  standardization  provides 
guidance  for  expressing  requirements,  but  not  for  the  requirements  themselves. 
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c.  Provide  an  approach  to  data  element  standardization  for  use  throughout 
ATCCIS  and,  potentially,  other  CCISs 

d.  Provide  a  means  to  ensure  consistency  of  data  throughout  NATO  and 
cooperating  national  databases  and  information  systems. 

(U)  Data  element  standardization  provides  an  opportunity  to  improve  the  quality 
and  consistency  of  specification  of  current  and  future  IERs.  Data  element  standardization 
presupposes  that  national  agreement  is  reached  in  formulating  and  structuring  the  required 
data  elements. 

(U)  The  complete  development  of  an  integrated  database  to  meet  these  requirements 
is  both  an  operational  and  technical  undertaking,  and  will  evolve  over  a  long  period  of  time. 
Working  Paper  7N3  will  present  the  overall  process  of  developing  the  necessary  technical 
basis  for  the  generation  of  an  integrated  set  of  databases  for  future  systems.  This  paper 
addresses  the  operational  input  to  that  overall  process. 

1.2  Purpose 

(U)  The  purpose  of  this  working  paper  is  to  provide  an  operational  input  to  data 
management  and  to  provide  specific  recommendations  for  data  standardization.  By 
providing  specific  recommendations,  this  paper  is  intended  to  promote  detailed  discussions 
that  could  result  in  early  promulgation  of  standards. 

1.3  Scope 

(U)  The  scope  of  data  element  standards  encompasses  data  used  to  support  CC1S 
missions  and  goals  in  support  of  coalition  warfare  and  the  entire  spectrum  of  conflict 
(peace,  transition  to  conflict,  and  conflict).  It  also  encompasses  data  required  to  support 
some  agencies  external  to  the  armies.  Standardized  data  elements  should  be  used  in 
specifying  EERs  for  all  CCISs. 

(U)  Standardization  procedures  provide  for  the  documentation  needed  to  coordinate 
data  sharing  across  the  armies.  Data  element  standardization  is  necessary  but  not 
sufficient  for  the  technical  specification  of  an  automated  database  ( see 
Working  Paper  7N  for  a  discussion  on  the  technical  issues  involved). 
Information  system  redesigns  provide  the  opportunity  to  align  existing  data  requirements 

3  (U)  Working  Paper  7N  on  Technical  Requirements  for  Data  Management  and  Standardization  is 

currently  being  developed  by  the  ATCCIS  PWG  Technical  Group.  Publication  date  to  be  determined. 
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with  the  standardized  data  elements.  Where  appropriate,  data  elements  currently  used  in 
existing  CCIS  databases  should  be  considered  for  adoption  as  standardized  data  elements. 

(U)  This  paper  accomplishes  several  goals: 

•  Recommends  that  a  NATO  glossary  be  developed  that  defines  all  the  terms  to 
be  used  to  name  and  characterize  the  structure  of  data  elements 

•  Recommends  a  naming  convention  for  the  identification  of  data  elements 

•  Recommends  an  attribute  set  for  characterizing  data  representations 

•  Identifies  requirements  and  proposes  an  approach  for  the  policies  and 
procedures  necessary  to  implement  and  maintain  effective  data  management 

1.4  Structure  of  the  Paper 

(U)  Chapter  2  provides  the  background  for  data  standardization.  The  approach  for 
data  standardization  is  based  on  structural  attributes  rather  than  how  the  data  are  used. 
Chapter  3  presents  the  basic  concepts  for  data  standardization,  including  the  concepts  of 
data,  data  element,  data  value,  and  data  field.  Chapter  4  presents,  based  on  proposed  draft 
International  Standards  Organization  (ISO)  standards,  the  conceptual  framework  for  the 
structure  of  data.  Chapter  5  discusses  the  need  for  a  Glossary  to  support  data 
standardization.  Chapter  6  proposes  a  data  element  naming  convention.  Chapter  7 
presents  a  set  (viewed  as  a  minimum  set)  of  attributes  need  to  specify  (e.g.,  in  a  data 
dictionary)  administrative,  representational,  and  relational  information  about  data  elements. 
Chapter  8  discusses  requirements,  policies,  and  procedures  for  data  management.  A  key 
element  of  the  data  management  concept  is  the  role  of  functional  experts  to  specify 
information  standards.  The  paper  concludes  in  Chapter  9  with  a  summary  of  the 
conclusions  and  recommendations. 
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2.  BACKGROUND  FOR  DATA  STANDARDIZATION 

(U)  Interoperability  for  ATCCIS  is  defined  as  the  exchange  of  information  that 
preserves  meaning  and  relationships.4 5  Data  standardization  is  required  to  provide 
consistent  structure  for  representing  these  meanings  and  relationships  for  data  elements  that 
support  the  EERs.  In  this  context,  the  term  "data  element"  refers  to  the  lowest  level  or 
simplest  expression  of  data  that  is  to  be  represented,  stored,  processed,  or  transmitted. 

(U)  The  data  management  problem  is  how  to  identify,  name,  and  structure  data 
elements  in  a  consistent  (and  nonredundant)  fashion  to  support  NATO  degree  five 
interoperability,  while  reducing,  or  at  least  controlling,  the  cost  of  modifying  or  developing 
ATCCIS-conformant  systems.  Data  management  is  required  for  correlating  lERs, 
designing  databases,  formatting  and  analysing  message  texts,  and  identifying  manual 
procedures. 

(U)  An  immediate  solution  for  the  data  management  problem  in  Allied  Command 
Europe  (ACE)  is  required.  Further,  there  is  not  yet  an  integrated  solution  (or  approach) 
defined  for  NATO  in  data  management.  A  discussion  of  the  policy  and  recommendations 
provided  to  date  is  given  in  Sections  2. 1  and  2.2. 

(U)  Each  data  element  in  a  CCIS  needs  to  have  associated  with  it: 

•  A  unique  name  that  is  structured  to  prevent  data  redundancy 

«  Representations  for  data  values  (e.g.,  formats,  range  of  acceptable  values) 

•  Indication  of  the  accuracy  of  the  data  element  (e.g.,  four  significant  places) 

•  Specification  of  the  unit  to  be  used  (e.g.,  litres) 

•  Additional  structure  to  represent  the  relationships  of  this  data  element  to  other 
data  elements  (e.g.,  associating  a  facility  name  with  a  logical  address) 

•  Supportive  descriptive  text. 

An  overview  of  concepts  for  data  and  data  standardization  is  presented  in  Chapter  3  and  4. 

(U)  The  concepts  to  be  used  for  names  and  structure  must  be  consistent  with 
international  standards  and  be  able  to  present  hierarchical  and  other  relationships.  Names 


4  (U)  The  basis  for  interoperability  in  ATCCIS  is  the  degree  five  interoperability  concept  as  defined  in 

the  15  December  1987  draft  NATO  Interoperability  Planning  Doci  ~ient  (NIPD)  [Ref.  8]. 
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themselves  will  be  given  structure.  Specifically,  naming  conventions  include  a 
fundamental  descriptor,  some  modifiers,  and  some  additional  qualifiers.  The  descriptors 
and  modifiers  would  specify  not  only  the  type  of  that  data  element,  but  also  a  clear 
indication  of  what  that  data  element  is.  One  of  the  underlying  principles  of  data 
standardization  is  that  data  elements  are  based  on  "what  is  represented"  rather  than  on  "how 
the  data  are  used."  Modifiers  would  also  indicate,  where  appropriate,  the  organizational 
context  or  meaning  for  the  data  element. 

2.1  NATO  Policy 

(U)  The  ATCCIS  Permanent  Working  Group  (PWG)  understands  that  NATO 
policy  for  data  management  is  the  responsibility  of  the  NATO  Communications  and 
Information  Systems  Committee  (NACISC).  However,  no  NACISC  policy  statements 
haye  been  found  for  data  management  This  section  summarizes  the  progress  being  made 
to  establish  the  need  for  and  to  develop  NATO  policy  for  data  management. 

(U)  The  Chairman  of  ADSIA  has  clearly  stated  [Ref.  6]  the  need  for  a  policy  for 
data  management  in  the  NATO  CCIS:5 

The  introduction  of  automated  data  bases  in  NATO  Commands  and 
Headquarters  over  the  past  decade  has  raised  the  need  for  interoperability 
standards  for  automated  information  exchange  among  data  bases  and  for  a 
scheme  for  data  management  to  insure  data  integrity  and  consistency  with 
CCIS  data  bases.  Various  NATO  authorities  are  already  forced  to  address 
those  activities  to  satisfy  specific  system  needs,  and  this  number  is 
increasing. ...[S]erious  attention  should  be  given  to: 

The  establishment  of  a  NATO  data  management  policy, 

The  development  of  a  NATO  CCIS  data  dictionary, 

The  development  of  interoperability  standards  for  database  information 
exchange. 

(U)  The  NATO  Interoperability  Management  Plan  (NIMP)  [Ref.  7]  specifically 
identifies  standards  and  rules  for  representing  data  as  procedural  standards  and  assigns  the 
responsibility  for  these  standards  to  ADSIA.  Further,  the  NIMP  states: 


5  (U)  The  NATO  CCIS  or  NCCIS  is  the  aggregation  of  NATO  Headquarters  systems,  NATO  Command 

systems,  NATO  Agency  systems,  national-NATO  dual-role  systems,  and  national  systems  that 
interface  to  NATO. 
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In  order  for  the  information  exchange  to  be  effective,  it  is  necessary  that  the 
meaning  and  relationships  associated  with  [information  received  from  other 
facilities]  is  common  and  preserved,  irrespective  of  the  interoperability 
service  and  transmission  media.  A  single  common  definition  for  all 
operational  information  throughout  NATO  is  needed  to  achieve  this  eoal. 
(Emphasis  added) 

...[A]  common  information  exchange  glossary  [is]  essential  to  the 
development  of  unambiguous  and  operationally  satisfactory  information 
procedural  standards. 

It  is  NATO  policy  to  maximize  the  commonality  of  the  different  system- 
dependent  standards  where  there  exists  a  validated  operational  requirement 
and  where  this  is  economically  acceptable.  The  areas  in  which  commonality 
shall  be  sought  include  operational  terminology,  expression  at  the 
representational  level  and  system  architecture. 

(U)  An  early  draft  of  the  NATO  Interoperability  Planning  Document  (NIPD) 
Volume  2  [Ref.  8]  had  an  annex  (Annex  D,  now  discarded)  that  described  a  Common 
Information  Exchange  Language  (CDEL)  that  was  a  predecessor  to  the  current  ADSIA 
initiative  to  develop  a  NATO  Glossary  of  Operational  Terms  (GLOT).  Details  are  provided 
in  Chapter  5.  The  NIPD  will  address  formal  specification  of  IERs  and  the  development, 
configuration  management,  testing  concept,  and  documentation  plan  for  NATO  Common 
Interoperability  Standards  (NCIS).  The  NIPD  is  still  in  development,  with  drafts  of  the  six 
volumes  planned  for  completion  in  1989  and  agreement  in  1990.  Drafts  of  Volume  2 
(Formal  Specification  of  IERs),  Volume  3  (Plan  for  Development  of  NCIS),  and  Volume  4 
(Plan  for  Configuration  Management  of  NCIS)  have  been  completed  [Ref.  9].  Volume  2 
will  specify  the  six  degrees  of  NATO  interoperability. 

(U)  Data  management  continues  to  be  carried  as  an  open  issue  on  the  agendas  of 
the  Information  Systems  Working  Group  (ISWG)  and  the  ADSIA  Plenary.6  The  ISWG 
has  been  invited  [Ref.  10]  by  the  ADSIA  Plenary  to  develop  a  NATO  policy  on  (1)  data 
management  and  (2)  the  use  of  database  management  systems  in  the  NATO  CCIS.  ADSIA 
would  use  this  policy  for  the  identification  and  collection  of  related  standardization 
requirements. 


6  (U)  Both  the  ISWG  and  ADSIA  are  part  of  the  NATO  Communications  and  Information  Systems 

Organization  (NACISO),  whose  executive  body  is  the  NACISC. 
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2.2  Overview  of  Existing  and  Emerging  Standards 

(U)  This  paper  will  recommend  an  integrated  framework  for  data  management  that 
brings  together  the  efforts  and  development  already  initiated  in  a  number  of  NATO 
Technical  Memorandums  and  other  papers,  as  well  as  from  international  commercial 
standards.  Selected  NATO  standardization  agreements  (STANAGs)  were  reviewed  to 
identify  potential  bases  for  data  management  standards.  This  section  summarizes  the  status 
of  standards  and  recommendations  from  these  sources. 

2.2.1  Existing  and  Emerging  ISO  Standards 

(U)  The  International  Standards  Organization  (ISO)  and  the  International 
Electrotechnical  Commission  (IEC)  Joint  Technical  Committee  1  (JTC1)  has  issued  a  draft 
standard,  DP  7826,  on  the  representation  of  data  elements  [Ref.  1 1],  This  draft  proposal 
sets  out  standard  procedures  for  the  identification  and  representation  of  existing  and  new 
coding  systems,  without  providing  any  guidance  on  specific  coding  systems.  It  also 
specifies  a  technique  for  interchange  of  coded  representations  and  the  requirements  for  the 
administration  of  International  Coding  System  Identifiers  (ICSIs).  This  will  permit  the  use 
of  more  than  one  coding  system,  reduce  the  possibility  of  ambiguity,  reduce  the  need  for 
human  intervention,  and  diminish  the  time  required  to  negotiate  interchange  of  coded 
representation  agreements. 

(U)  ISO/IEC  DP  7826  identifies  three  types  of  data  element  attributes: 
administrative,  relational,  and  representative.  These  are  the  types  of  attributes  described  in 
this  Working  Paper  and  recommended  for  ATCCIS  in  Chapter  7. 

(U)  Substantial  work  has  been  done  cooperatively  by  ISO/IEC  JTC1/SC14  and 
American  National  Standards  Institute  (ANSI)  X3L87  during  the  last  three  years,  and  a 
draft  proposal  for  data  management  is  expected  sometime  in  1989.  Once  accepted  by  the 
working  groups,  this  draft  proposal  will  be  offered  to  ISO  for  adoption  [Ref.  12].  The 
general  approach  to  the  structure  of  data  (Chapter  4)  was  derived  from  discussions  with 
ISO/IEC  JTC1/SC14  and  ANSI  X3L8. 


7  (U)  A  member  of  the  U.S.  Technical  Advisory  Group  to  ISO/IEC  JTC1/SC14  and  of  X3L8  is  an 

active  participant  in  the  ATCCIS  PWG  and  contributed  to  this  Working  Paper. 
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2.2.2  STANAGs  and  TSGCEE  Recommendations 

(U)  The  purpose  of  AAP-6,  NATO  Glossary  of  Terms  and  Definitions  (English 
and  French )  [Ref.  13],  is  to  standardize  operational  terminology  used  throughout  NATO, 
thereby  promoting  mutual  understanding.  The  criterion  for  inclusion  is  that  the  term  be  of  a 
general  military  application.  While  earlier  editions  put  qualifiers  immediately  following  the 
term,  such  qualifiers  are  now  embedded  in  the  definition.  In  addition,  terms  and 
definitions  are  not  to  be  composed  of,  nor  contain,  abbreviations  and  acronyms.  A  term 
and  definition  are  only  included  in  the  glossary  when  they  have  been  agreed  upon  by  all 
nations  in  both  English  and  French. 

(U)  An  early  standard,  no  longer  in  effect,  was  ADatP-1  (STANAG  5550)  [Ref. 
14],  NATO  Standard  Data  Elements,  Data  Items,  and  Codes.  This  standard  was  developed 
to  specify  the  rules  and  procedures  in  developing  standard  data  suitable  for  use  in  both 
manual  and  computer-assisted  environments  for  the  exchange  of  information  between 
national  and  NATO  authorities. 

(U)  The  terms  defined  in  ADatP-2  [Ref.  15],  Automatic  Data  Processing  (ADP) 
NATO  Glossary,  English  and  French,  are  derived  from  glossaries,  dictionaries,  and 
vocabularies  from  ANSI,  American  National  Directory  for  Information  Processing 
(ANDEP),  ISO,  International  Business  Machines  (IBM),  and  ACP  167.  The  definitions  arc 
annotated  by  source  and  may  include  abbreviations,  examples,  notes,  diagrams,  accepted 
synonyms,  contrasting  terms,  related  terms,  and  cross-references  for  multiple  uses.  When 
harmonization  is  being  examined  for  multiple  uses  of  a  term,  this  information  is  noted. 

(U)  ADatP-3  (STANAG  5500)  [Ref.  16],  NATO  Message  Text  Formatting  System 
(FORMETS),  provides  the  rules,  constructions,  and  vocabulary  for  standardized  character- 
oriented  message  text  formats  that  can  be  used  in  both  manual  and  computer-assisted 
operational  environments. 

(U)  Allied  Communications  Publication  (ACP)  167(F)  [Ref.  17],  Glossary  of 
Communications-Electronics  Terms,  provides  definitions  of  terms  used  by 
communications,  electronic  warfare,  and  operational  personnel  for  Allied  networks. 

(U)  STANAG  5621  is  one  of  many  operational  standards  that  provide  procedures 
for  embedding  data  fields  into  (character-oriented)  message  text  formats.  However,  it 
does  not  provide  a  structured  method  for  the  integration,  identification,  or 
naming  of  data  elements  that  is  applicable  across  multiple  media.  Users 
provide  free-form  names  for  data  fields.  Associated  with  each  data  field  is  a  set  format 
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identifier,  whose  first  character  indicates  whether  the  data  field  set  format  is  designed  for 
columnar  information. 

(U)  STANAG  4222,  Standard  Specification  for  D:jital  Representation  of 
Shipboard  Data  Parameters,  is  a  naval  standard  that  addresses  naming  conventions  [a 
product  of  the  NATO  Industrial  Advisory  Group  (NIAG)  WG6].  This  STANAG 
addresses  the  specification  of  digital  representation  of  shipboard  embedded  data  parameters 
only. 

(U)  The  NATO  Technical  Common  Interoperability  Standards  (TCI S)  Transition 
Strategy  [Ref.  18]  recommends  a  number  of  ISO  standards  for  use  until  the  TCIS  are 
available.  These  technical  standards  include  ASN.l  (ISO  8824),  ASN.l  Basic  Encoding 
Rules  (ISO  8825),  and  Association  Control  Service  Elements  (ASCE,  ISO  8650),  which 
could  support  the  procedural  standards  recommended  in  this  Working  Paper  for  data 
management 

2.2,3  Other  NATO  Directives  and  Recommendations 

(U)  In  1985,  STC  published  a  Technical  Memorandum  (TM),  Data  Management 
Standardization  for  ACE  ACCIS,  TM-776  [Ref.  5].  This  paper  recommends 
standardization  of  the  architecture,  functionality,  and  structure  of  the  Data  Management 
Subsystem  (DMS)  of  the  ACE  Automated  Command  and  Control  Information  System 
(ACCIS).  These  areas  of  standardization  include  data  management  methodologies  and  the 
tools  needed  to  design,  build,  and  maintain  the  ACE  ACCIS  databases.  TM-776 
accomplished  the  following: 

•  Recommended  standard  data  elements  and  relationships  be  placed  into  an  ACE 
common  data  structure. 

•  Identified  a  schema  as  consisting  of  a  definition  of  all  application  object  types, 
including  their  attributes,  relationships,  and  static  constraints,  where  a  database 
is  an  instance  of  a  schema. 

•  Identified  the  need  for  a  methodology  for  formal  definition  of  data  elements 
based  on  standardized  terminology,  including  the  use  of  naming  conventions. 

•  Identified  the  requirement  that  the  Data  Management  Subsystem  (DMS)  at 
every  ACE  ACCIS  node  must  agree  upon  the  semantics  and  syntax  of  the 
information  exchange. 

•  Stated  that  a  classification  method  must  be  based  on  the  principle  of  sorting 
data  according  to  the  type  of  information  provided  by  their  values,  independent 
of  their  use  in  particular  databases,  messages,  or  applications 
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•  Defined  a  data  element  as  a  basic  unit  of  data  which  has  a  name,  a  definition, 
and  a  set  of  values  for  representing  particular  facts.  A  data  element  and  its 
definition  should  not  include  any  application  or  usage  information. 

•  Stated  that  determination  of  names  following  rules  and  classification  of  data 
elements  brings  out  common  data  features  and  helps  the  correlation  process.  A 
method  of  analysing,  defining,  and  controlling  data  elements  has  three 
components:  a  type  classification  of  data  elements,  syntax  rules  for  the 
structure  and  completeness  of  formal  definitions,  and  a  controlled  vocabulary 
of  permitted  terms  for  formal  definitions.  (Note:  the  concept  of  generic 
element  is  introduced  in  Chapter  3  to  provide  for  these  features.) 

(U)  In  April  1986,  ADSIA  revised  a  working  paper,  "The  Need  for  Standardization 
of  Data  Management  and  Data  Base  Information  Exchange  in  the  NATO  CCIS"  [Ref.  3], 
on  the  need  for  standardization  of  data  management.  The  following  actions  were 
recommended  and  agreed  to,  but  without  any  binding  commitments  of  the 
nations  to  implement  them: 

•  NATO  Communications  and  Information  Systems  Agency  (NACISA)  to 
identify  and  collect  the  requirements  for  database  management  systems  and  for 
standardization  of  database  schemes,  file  transfers,  database  information 
exchange,  and  configuration  management  procedures 

•  Subsequently,  ISWG  to  develop  a  NATO  policy  on  data  management  and  on 
the  use  of  database  management  systems  in  NATO  CCISs 

•  ADSIA  to  coordinate  the  development  of  technical  and  procedural  standards  for 
databases 

•  ADSIA  to  develop  the  procedural  standards  for  database  information  exchange 

•  TSGCEE  Subgroup  9  on  Data  Processing  and  Distribution  to  develop  technical 
standards  for  database  schemes  and  file  transfer 

•  NACISA  to  control  the  implementation  of  the  developed  standards  and  NATO 
policy  paper  to  ensure  the  interoperability  of  command  and  control  systems 
within  the  NATO  CCIS. 

(U)  In  October  1988,  SHAPE  distributed  AM  96-1-4,  Data  Management  [Ref.  4]. 
This  manual  concentrates  primarily  on  administrative  aspects  of  data  management, 
specifically  the  responsibilities  of  a  Data  Administrator  and  a  Database  Administrator.8  It 
states: 


8  (U)  AM  96-1-4  is  binding  only  on  SHAPE.  As  such,  it  does  not  necessarily  provide  for  NATO-wide 

policy. 
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•  The  purpose  of  data  management  is  to  provide  methods  to  ensure  data 
availability,  security,  integrity,  quality,  and  interoperability,  and  to  provide 
data  sharing. 

•  Defines  data  as  representing  the  elementary  facts,  descriptions,  and 
qualifications  about  things  of  interest  to  some  headquarters,  unit  activity,  or 
enterprise. 

•  Defines  an  attribute  as  a  definitive  characteristic  of  a  data  element  or  data  item 
that  quantifies,  identifies,  or  describes  its  representational,  administrative,  or 
relational  concept. 

•  Defines  the  role  of  a  data  dictionary  as  an  automated  tool  that  provides  a 
centralized  library  of  metadata  covering  all  aspects  of  all  types  and  structures  of 
data  residing  in  databases,  file  systems,  and  manual  systems  within  an 
organization.  Aspects  identified  are: 

origin  and  ownership  of  data 

attributes  (name,  number,  code  language  mnemonic,  synonyms,  format, 
range  of  values) 

definitions 

usage  (applications,  reports,  physical  forms) 

location  (files,  schemas) 

destination  (data  flows) 

security  classification 

relationships 

dispositions. 

•  Asserts:  Evolution  towards  an  ACE  ACCIS  will  only  succeed  from  the  data 
management  point  of  view  by  ensuring  that  the  standardization  of  data 
definitions,  the  control  of  the  data,  and  the  maintenance  of  its  overall  integrity 
are  systematically  established  on  a  command  or  site  basis. 

•  Asserts:  The  fundamental  key  to  data  management  is  the  early  definition  and 
identification  of  data  elements  and,  later,  data  fields.  The  definition  and 
corresponding  name  should  be  clear,  accurate,  and  meaningful,  but  reference 
should  be  given  to  connotation,  which  relates  to  the  interpretation  that  bears 
upon  the  specific  context  of  usage  of  data. 

2.2.4  Other  Data  Management  Standards 

(U)  The  naming  convention  and  rules  presented  in  this  paper  have  been  derived 
from  an  emerging  standard  from  the  National  Institute  for  Science  and  Technology  (NIST), 
Guide  to  Data  Entity  Naming  Conventions  [Ref.  19],  that  is  expected  to  be  offered  to  ISO 
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in  the  near  future.  Specifically,  the  general  format  of  the  convention  is  consistent  with  this 
publication.  However,  the  rules  have  been  expanded  to  support  the  concepts  and  structure 
of  data  consistent  with  the  needs  in  NATO,  SHAPE,  and  ATCCIS,  as  well  as  the  emerging 
ISO  taxonomy.  The  attribute  list  presented  in  Chapter  7  is  a  superset  of  the  element  level  of 
ISO/EEC  DP  10027,  Information  Processing  Systems-Information  Resource  Dictionary 
System  ( IRDS )  Framework  of  1  April  1988.  The  attribute  list  (as  well  as  the  rules)  has 
been  expanded  to  incorporate  needs  that  have  been  identified  in  NATO,  SHAPE,  and 
ATCCIS.  The  overall  guiding  philosophy  has  been  to  integrate  all  possible  sources  of 
information  on  data  management,  standardization,  standards,  structure,  classification,  and 
typing. 

(U)  The  concepts  and  constructs  contained  within  this  paper  are  consistent  with  the 
emerging  IRDS  standard,  ISO/IEC  DP  10027.  The  IRDS  specifies  the  Element  Entity 
(i.e.,  data  element)  as  the  lowest  level  of  the  dictionary  framework.  Unfortunately,  the 
IRDS  does  not  address  the  constructs  that  make  up  the  Element  Entity,  nor  does  it  provide 
a  convention  that  can  be  used  to  support  the  Element  Entity.  This  paper  supports  and 
completes  the  Element  Entity  as  defined  within  ISO/EEC  DP  10027  by  providing  an 
approach  that  will  facilitate  the  standardization  and  management  of  the  IRDS’s  Element 
Entity. 

(U)  In  ACE  Directive  80-57,  SHAPE  has  recommended  use  of  the  Structured 
Analysis,  Design,  and  Implementation  of  Information  Systems  (STRADIS)  Methodology 
(AM  96-1-2  [Ref.  20]  and  AM  96-1-3  [Ref.  21])  as  an  an  ACE  formal  life-cycle 
methodology  for  the  implementation  of  all  software  projects.9  It  includes  extensive 
activities  related  to  data  identification  and  analysis  as  part  of  its  structured  requirements 
analysis  phase.  STRADIS  gives  rules  and  guidance  to  be  followed  by  management  and 
implementors,  and  it  gives  recommendations  on  which  methodologies  should  be  used  for 
the  data  analysis  and  database  design  phases.  Specifically,  STRADIS  recommends 
[Ref.  5]: 

•  Use  of  the  Yourdon  data  analysis  technique  (structured  analysis,  using  data 
flow  diagrams)  [Ref.  22,  23,  24] 

•  Structured  walkthroughs  [Ref.  23,  25] 


9  (U)  STRADIS  was  developed  by  the  McDonnell  Douglas  Corporation.  It  is  still  proprietary  and 

distribution  in  ACE  is  limited.  The  two-volume  document  has  been  revised  to  five  volumes,  but  these 
have  not  yet  been  procured  by  SHAPE. 
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•  Data  normalization  [Ref.  26] 

•  Automated  support  tools,  including  EXCELERATOR  and  DATA  DESIGNER. 

The  STRADIS  Project  Data  Dictionary  is  viewed  as  a  repository  for  project  metadata,  the 
contents  of  which  are  to  be  compared  with,  and  be  expected  to  lead  to  eventual  merging 
with,  existing  conceptual  schema.  The  STRADIS  also  generates  Project  Entity- 
Relationship,  Key-based,  and  Fully  Attributed  models  that  are  considered  prototype 
external  schema  for  particular  functional  areas  [Ref.  4]. 

2.3  Operational  Rationale  for  Data  Standardization 

(U)  Command  and  control  of  military  forces  is  accomplished  through  information 
and  is  often  supported  by  automation.  The  information  flow  required  to  support  command 
and  control  has  evolved  over  the  years  to  a  current  system  that  is  highly  complex  and  often 
automated.  Military  leaders  today  are  faced  with  unparalleled  dynamics  in  the  coalition 
warfare  environment  and  an  information  level  that  is  growing  exponentially. 

(U)  The  proliferation  of  automated  office  and  tactical  information  systems  has 
increased  by  varying  factors  in  each  nation's  tactical  formations.  Similarly,  the  ACE 
ACCIS  System  Design  and  Integration  Contract,  War  HQ's  project,  along  with  national 
plans  for  the  tactical  forces,  will  provide  additional  command  and  control  information 
systems  at  the  various  echelons  and  headquarters  within  ACE.  NATO  has  identified  the 
need  for  these  systems  to  be  interoperable,  and  that  information  management  is  a  required 
strategic  and  operational  capability. 

(U)  The  ability  to  effectively  command  and  control  forces  on  the  battlefield  and 
manage  information  resources  requires  that  operational,  procedural,  and  technical  standards 
be  agreed  upon  and  implemented.  The  current  Operational  and  Procedural  standards 
identify  less  than  half  of  the  IERs  required  by  tactical  forces.  The  current  methods  of 
exchanging  information  [e.g.,  Message  Text  Formats  (MTFs),  voice,  and  formatted  data] 
result  in  redundant  transmission  of  information,  misunderstanding,  and  inconsistency  in 
interpretation,  and  they  place  an  additional  burden  on  limited  tactical  communications 
systems. 

(U)  Data  standardization,  including  agreed  operational  definition  of  the  information 
to  be  exchanged  among  the  nations,  is  one  of  the  key  issues  identified  in  the  ATCCIS 
study.  While  the  focus  for  ATCCIS  is  the  next  generation  of  tactical  systems,  this  work 
must  be  started  now. 
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3  .  CONCEPT  OF  DATA 

(U)  Agreement  is  needed  for  a  concept  of  data  in  order  to  provide  an  overall 
mechanism  to  express  precise  meanings  and  relationships  of  data  to  be  exchanged  in 
support  of  interoperability  requirements.  This  chapter  and  Chapter  4  present  fundamental 
concepts  on  data  and  data  structure  that  are  technical  in  nature.  They  are  presented  here  for 
completeness,  since  much  of  the  discussions  in  Chapters  6,  7,  and  8  are  based  on  these 
concepts. 

3.1  Concept  of  Data 

(U)  In  information  systems,  the  basic  unit  of  information  is  data.  In  this  context, 
data  refers  to  that  unit  that  contains,  but  is  not  limited  to,  such  things  as:  raw  number, 
word(s)  of  text,  codes,  or  graphical  pixel  representation.  Formally,  data  may  be  defined  as 
a  representation  of  a  person,  place,  thing,  or  concept  in  a  pre-defined  format  or  structure 
from  which  information  can  be  derived. 10  The  distinction  between  data  and  information  is 
that,  in  and  of  itself,  data  has  no  meaning.  Information  has  some  contextual  meaning 
attached  to  it,  such  that  the  use  of  that  information  can  relate  it  to  an  aspect  of  the  real 
world.  As  an  example,  the  individual  pixels  (data)  that  make  up  a  graphical  image  have  the 
intended  meaning  (information)  only  when  related  to  other  pixels  in  a  predefined  way. 
When  stored  in  manual  or  automated  information  systems,  the  actual  occurrence  of  data  is 
called  a  data  value. 

(U)  The  October  1988  AM  96-1-4  [Ref.  4]  identifies  a  hierarchy  of  three 
fundamental  data  concepts: 

•  Data  Element.  This  represents  a  named  piece  of  data  that  is  of  interest  to  an 
organization.  In  order  to  make  sense,  it  should  be  carefully  and 
unambiguously  defined,  together  with  other  characteristics  or  attributes  that  can 
help  to  express  its  content.  A  data  element  represents  a  master  identification 
and  description  of  the  logical  need  for  some  item  of  data  in  an  organization. 

*  Data  Value.  Represents  a  discreet  "instance"  of  a  data  element  and  is  what  is  of 
most  interest  to  the  end  user-actual  data  upon  which  processing  is  undertaken 
and  information  is  derived. 


10  (U)  Data  is  defined  in  ISO  2382  (and  in  DP  7826)  as  'a  representation  of  facts,  concepts,  or 
instructions  in  a  formalized  manner  suitable  for  communication,  interpretation,  or  processing  by 
humans  or  by  automatic  means." 
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•  Data  Field.  The  smallest  unit  of  data  that  has  meaning  in  describing 
information;  the  smallest  unit  of  named  data. 

(U)  The  logical  connection  between  these  concepts  is  as  follows.  The  data  element 
is  the  object  of  management  within  a  data  management  and  standardization  program.  Each 
data  element  is  functionally  described,  together  with  a  set  of  data  values  that  are  acceptable 
for  each  standardized  data  element  that  is  adopted.  Thus,  each  data  element  has  a  set  of 
specified  data  values  that  an  appropriate  authority  has  deemed  correct  and  of  interest  to  the 
organization.  The  data  field  is  the  physical  location  of  an  instance  of  a  data  value  within  an 
operational  database.  This  means  that  the  only  entities  that  may  occupy  a  data  field  are  the 
acceptable  data  values  that  have  been  deemed  acceptable  for  the  associated  data  element 

3.2  Categorization  of  Data  Concepts 

(U)  Each  of  the  three  data  concepts  (data  element,  data  value,  and  data  field)  can  be 
categorized  in  two  ways.  The  first  is  to  distinguish  qualitative  data  from  quantitative  data; 
this  is  known  in  ISO  as  data  classification.  The  second  categorization  is  by  data  type,  in 
which  there  are  traditionally  six  types:  character  string,  bit  string,  float  (or  floating  point), 
fixed-point,  integer,  and  boolean  (logical). 

(U)  The  purpose  of  the  two  categories,  data  classification  and  data  typing,  is  to 
provide  a  common  framework  for  discussing  data  concepts  and  to  ensure  data  is 
consistently  treated  and  processed  in  software.  Appendix  A  contains  a  further  discussion 
of  data  classification  and  data  types,  including  the  definitions  of  each  data  type. 

3.3  Data  Element  Concepts 

(U)  A  generic  element  is  a  concept  of  data.  It  is  distinguished  from  other  concepts 
of  data  in  that  every  generic  element  has  a  precise,  well-defined  set  of  those  possible  values 
that  the  generic  element  can  take  on.  This  means  that,  whenever  a  value  is  considered,  it  is 
always  possible  to  determine  whether  that  value  is  one  permitted  to  be  taken  on  by  the 
generic  element.  As  an  example,  the  term  "aircraft"  is  a  concept  of  data  that,  standing 
alone,  is  not  a  generic  element,  since  there  is  not  a  clear  agreement  as  to  the  entire  set  of 
possible  values.  On  the  other  hand,  a  two-character  country  code-of-world  is  a  generic 
element  commonly  used  in  international  commerce,  where  ISO  has  the  responsibility  for 
maintaining  the  agreed  set  of  values. 

(U)  The  term  data  element  is  used  to  identify  those  generic  elements  that  have  been 
assigned  an  organizational  context,  including  an  organizational  description  of  what  the  data 
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element  is.  For  example,  the  concept  "date"  is  a  generic  element.  A  related  data  element 
"personnel  information  last  modified  date"  has  an  organizational  context.  One  of  the 
difficult  problems  in  data  management  is  that  the  distinction  between  generic  elements  and 
data  elements  is  vague  and  subject  to  interpretation. 

(U)  The  concepts  of  generic  element  and  data  element  introduced  above  are  both 
constrained  by  needing  an  agreed  set  of  acceptable  values.  This  limitation  is  called  a 
domain.  The  two  types  of  domains,  specific  and  general,  are  discussed  in  Appendix  A, 
Section  III. 

3.4  Data  Element  Alias 

(U)  One  of  the  problems  in  data  element  standardization  is  deciding  how  to  handle 
previously  defined  data  elements  and  implementing  concepts  in  separate  systems  that  are 
essentially  the  same  data  element  To  standardize  such  a  data  element,  a  single  data  element 
representation  is  adopted  as  a  standard,  and  the  other  occurrences  are  treated  as  data 
element  aliases.  A  data  element  alias  can  differ  from  the  standardized  data  element  in  the 
content  of  administrative,  representational,  or  administrative  attributes.  Such  attributes,  as 
well  as  the  concept  of  data  element  alias,  are  treated  more  fully  in  Chapter  4. 
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4.  STRUCTURE  OF  DATA 

(U)  The  concepts  discussed  in  this  paper  are  taken  from  ANSI  X3L8,  Project  993T 
(this  work  is  currently  being  drafted  as  an  ISO  DP  by  Working  Group  4  of  ISO/JTCl,  SC 
14).  There  are  differences  between  these  concepts  and  related  concepts  in  ACE  Manual  96- 
1-4.  The  ISO  source  was  taken  because  it  specifies  further  the  concept  of  data  element  and 
its  relationship  to  common  sets  of  data  values.  This  allows  for  the  economy  of  scales  in 
data  standardization,  and  enhances  the  potential  for  reduced  data  redundancy  and  enhanced 
interoperability.  ACE  Manual  96-1-4  does  not  go  far  enough  in  defining  these  concepts. 

(U)  Additionally,  through  the  use  of  a  generic  element,  the  structure  of  the  data 
element  can  be  standardized  on  a  set  of  values  as  opposed  to  the  manner  in  which  the  data 
are  used.  The  latter  approach  (standardizing  on  use)  introduces  multiple  occurrences  into 
what  might  otherwise  be  a  single  data  element  and  increases  the  potential  for  data 
redundancy.  Indeed,  when  standardization  on  use  occurs,  multiple  data  elements  can  be 
created  for  a  single  data  element  since  the  name  of  the  data  element  will  reflect  how  those 
data  are  used,  and  not  what  they  are.  It  must  be  emphasized  that  NATO  standardization 
must  occur  on  structure  and  NOT  on  use  of  a  data  element.  (This  is,  in  fact,  the  approach 
recommended  by  STC  for  ACE  ACCIS:  "...classification.. .is  based  on  the  principle  of 
sorting  data  according  to  the  type  of  information  provided  by  their  values. ..independently 
of  their  use."  [Ref.  5])  The  use  of  uniform  structures  eliminates  the  problem  mentioned 
above,  and  improves  communications  and  interoperability  since  there  is  a  common  data 
foundation.  This  foundation  does  not  require  systems  or  individuals  to  use  a  "translation" 
or  "bridge"  to  interpret  the  contents  of  a  data  element  or  group  of  data  elements,  as  in  an 
IER. 


4 . 1  Generic  Element 

(U)  A  generic  element  is  a  structure  in  data  management  that  is  used  to  specify  a  set 
of  data  values.  Such  a  set  can  be  used  to  support  several  data  elements.  A  common  set  of 
values  can  be  used  by  many  different  data  elements  that  identify  what  different  things  are  in 
relation  to  the  real  world  or  organizational  environment.  In  other  words,  a  generic  element 
has  no  organizational  reference  associated  with  its  structure.  As  an  example,  the  data  value 
for  COUNTRY  CODE  OF  WORLD  ”FR"  has  no  context  in  and  of  itself-one  can  assume  it 
stands  for  France— but  there  is  no  understanding  of  what  it  represents  in  an  organizational 
reference.  Contexts  of  such  a  generic  element  could  be  geographic,  political,  biographic, 
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or  economic,  as  well  as  military.  Thus,  the  code  structure  can  be  used  in  many  contexts  to 
form  different  data  elements,  while  still  conforming  to  a  single  agreed  to  structure. 

(U)  The  generic  element  is  specified  by  a  collection  of  attributes  that  convey  the 
technical  information  associated  with  a  given  generic  element  These  attributes  are  divided 
into  three  categories:  administrative,  relational,  and  representational.  The  administrative 
attributes  address  the  descriptive  type  of  information  about  the  generic  element.  The  most 
important  attribute  is  the  name  of  the  generic  element,  which  is  unique  and  structured  for 
identification  purposes.  (A  full  discussion  of  the  naming  of  the  generic  element  and  data 
element  is  provided  in  Chapter  6.)  The  relational  attributes  give  information  about  the 
generic  element's  connection  to  a  controlling  organization  or  agency.  The  representational 
attributes  identify  information  about  a  common  set  of  data  values. 

(U)  Figure  1  illustrates  the  structure  of  a  generic  element.  It  shows  that  a  generic 
element  is  composed  of  three  types  of  attributes.  One  of  these  attributes  will  be  its  name. 
A  proposed  set  of  attributes  for  generic  elements  has  been  compiled  from  various  national 
and  international  documents.  These  attributes  are  discussed  in  Chapter  7. 
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Figure  1.  (U)  Generic  Element  Structure- A  Collection  of  Attributes 
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(U)  There  are  two  constraints  that  need  to  be  imposed  on  generic  elements.  These 
constraints  are  designed  to  assist  in  the  standardization  process  and  help  maintain  data 
integrity.  These  two  constraints  are: 

(1)  A  generic  element  is  unique  to  a  single  concept. 

(2)  A  generic  element's  set  of  values  will  not  be  a  subset  of  the  values  that  have 
been  enumerated  by  another  generic  element 

4.2  Data  Element 

TJ)  A  data  element,  as  previously  defined,  represents  what  an  object  is  and 
determines  the  organizational  context  of  a  generic  element.  In  other  words,  the  structure 
specified  in  the  generic  element  is  formulated  into  a  data  element  that  identifies  what  that 
data  element  is  in  relation  to  the  real  world.  This  identification  process  is  based  on  the 
"what  it  is"  aspect  of  the  data  and  not  on  "how  I  am  going  to  use  it."  To  continue  with  the 
"country  code"  example,  if  a  data  element  were  constructed  to  code  the  members  of  the 
ATCCIS  Working  Group  Nations,  "FR"  could  be  used  as  data  value  for  an  ATCCIS 
Working  Group  Country  Code-of- World.  The  generic  element  "Country  Code-of- World" 
provides  a  common  structure  for  country  codes,  and  this  instance  of  the  data  element 
identifies  the  particular  members  of  a  SHAPE  body. 

(U)  The  data  element,  like  the  generic  element,  is  specified  by  a  collection  of 
attributes  that  convey  technical  information.  When  the  data  element  is  constructed, 
attributes  are  added  to  those  of  the  generic  element  to  form  a  complete  identification  and 
description  of  the  data  element.  Data  element  attributes  are  also  divided  into  three 
categories:  administrative,  relational,  and  representational.  As  before,  the  administrative 
attributes  address  the  descriptive  type  of  information  about  the  data  element,  and  the  most 
important  attribute  is  the  name  of  the  data  element  that  is  unique  and  structured  for 
identification  purposes.  (A  full  discussion  of  the  naming  conventions  for  both  the  data 
element  and  generic  element  is  provided  in  Chapter  6.) 

(U)  Figure  2  illustrates  the  structure  of  a  data  element.  The  figure  shows  that  the 
data  element  includes  all  the  attributes  of  the  generic  element  to  which  it  is  associated.  A 
proposed  set  of  attributes  for  data  elements  has  been  compiled  from  various  national  and 
international  documents.  These  attributes  are  discussed  in  Chapter  7. 
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Figure  2.  (U)  Data  Element 

(U)  There  are  a  few  constraints  that  need  to  be  imposed  on  data  elements.  These 
constraints  are  designed  to  assist  in  the  standardization  process  and  help  maintain  data 
integrity.  The  constraints  are: 

•  A  data  element’s  values  will  not  be  a  subset  of  the  values  that  have  been 
enumerated  by  another  data  element 

•  A  data  element's  values  will  either  be  the  same  set  or  a  subset  of  the  generic 
element's  values  used  to  structure  the  data  element. 

•  Data  elements  that  are  derived  through  chaining,  computation,  or  calculation 
should  be  treated  as  any  other  data  element. 

•  Multiple  uses  or  "ordinal  representations"  of  a  data  element  will  not  be 
approved  as  separate  standards.  As  an  example,  personnel  data  elements  often 
capture  the  successive  dates  of  the  first,  second,  third,  etc.,  occasion  that  the 
same  award  is  presented  to  a  soldier.  These  would  be  designated  a  single  data 
element,  which  could  be  used  several  times,  as  opposed  to  creating  three  or 
more  different  data  elements. 
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4.3  Data  Element  Alias 

(U)  A  data  element  alias  is  used  to  identify  data  elements  in  use  in  a  specific 
information  system  at  a  specific  location.  Data  elements  that  are  aliases  differ  from 
standard  data  elements  in  one  or  more  of  the  attributes  that  have  been  specified  for  the 
standardized  data  element.  Often,  the  differences  will  be  in  the  name,  the  description,  the 
set  of  data  values,  or  other  representational  attributes.  This  mechanism  is  used  to  bridge 
current  national  data  elements  in  fielded  information  systems  to  the  proposed  or  actual 
CCIS  data  element  standards,  when  and  if  differences  exist.  As  information  systems  are 
redesigned,  the  use  of  the  data  element  alias  should  be  eliminated  in  order  to  facilitate  cost 
reduction  and  facilitate  communications  in  a  coalition  warfare  environment 

(U)  Figure  3  illustrates  the  structure  of  a  data  element  alias.  It  shows  that  some  of 
the  attributes  of  the  data  element  alias  can  differ  from  its  associated  data  element.  As  an 
example  of  an  alias,  assume  the  US  "UNIT  IDENTIFICATION  CODE"  had  a  slightly 
different  structure  from  the  one  specified  in  STAN  AG  5621;  in  this  case,11  the  US  data 
element  "UNIT  IDENTIFICATION  CODE"  would  be  made  an  alias  to  the  NATO 
standard.  In  the  alias  specification  the  differences  would  be  explicitly  identified. 

(U)  A  proposed  set  of  attributes  for  the  data  element  alias  has  been  compiled  from 
various  national  and  international  documents.  These  attributes  are  discussed  in  Chapter  7. 


1 1  (U)  This  example  was  taken  from  STAN  AG  5621,  Appendix  3  to  Annex  A, 


UNCLASSIFIED. 


23 

UNCLASSIFIED 


UNCLASSIFIED 


Element 


Differences 
Permitted  In: 

Administrative 

Attributes 


Relational 
Attributes 
—  —  —  ■  ■■■  -  w 


Representational 

Attributes 


UNCLASSIFIED 

Figure  3.  (U)  Data  Element  Alias 
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5  .  DATA  MANAGEMENT  GLOSSARY 

(U)  A  glossary  is  needed  to  ensure  a  consistent  definition  is  provided  for  all  terms 
used  in  IERs,  as  well  as  in  the  specification  of  generic  elements  and  data  elements.  This 
chapter  provides  background,  purpose,  and  recommendations  for  a  NATO  data 
management  glossary. 

5.1  Background 

(U)  This  chapter  discusses  NATO  initiatives  toward  a  glossary.  An  early  concept, 
the  Common  Information  Exchange  Language  (CIEL),  originally  developed  by  ADSIA 
[Ref.  27]  and  specified  in  an  early  draft  of  the  NIPD  [Ref.  28],  was  disapproved  by  the 
15th  ADSIA  Plenary  in  1986  [Ref.  29].  An  overview  of  the  now  abandoned  CIEL  is 
provided  as  background;  it  is  followed  by  a  discussion  of  the  NATO  Common  Information 
Exchange  Glossary  (CIEG),  now  known  as  the  Glossary  of  Operational  Terms  (GLOT), 
which  could  be  incorporated  into  AAP-6  or  published  separately  as  AAP-25. 

5.2  Common  Information  Exchange  Language  (CIEL) 

(U)  The  CIEL12  was  originally  specified  in  an  early  draft  of  the  NIMP  to  be  that 
portion  of  the  NATO  Common  Interface  Standards  (NCIS)  that  is  procedural  in  nature. 
The  three  parts  of  the  CIEL  were  a  dictionary,  a  character-oriented  message  notation,  and  a 
bit-oriented  message  notation. 

•  The  data  element  dictionary  of  CIEL  was  the  one  defined  for  NATO  in 
ADatP-1  [Ref.  14]  (no  longer  in  effect;  see  Section  2.2.2). 

•  The  character-oriented  message  notation  already  established  for  NATO  and 
included  in  the  CIEL  is  FORMETS  as  defined  in  ADatP-3  (STANAG  5500). 
FORMETS  provides  a  formal  notation  for  specifying  both  an  abstract  syntax 
(notations  used  in  applications  for  information  transfer  that  does  not  actually 
determine  the  representation  to  be  used  for  data  element  values)  and  a  concrete 
syntax  (the  transfer  syntax  derived  from  the  abstract  syntax  in  a  particular 
application  using  encoding  rules). 

•  The  bit-oriented  message  notation  for  CIEL  was  the  tactical  data  link  language 
of  ADatP-5,  NATO  Data  Link  Message  Standards  (D ALIMS)  [Ref.  30,  now 
abandoned].  The  function  of  this  language  was  to  provide  a  means  to  compile 
pictures  and  transmit  command  and  control  orders,  weapons  assignment,  and 


12 


(U)  The  discussion  of  CIEL  is  taken  from  "CIEL  Discussion  Paper"  [Ref-  24], 
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control  orders  in  real  time  or  near  real  time.  DALIMS  used  data  link  message 
formats  with  bit  encoding  techniques.  The  goal  of  DALIMS  was  to  provide  a 
language  that  uses  only  standard  bit  fields  common  to  all  tactical  data  systems. 

(U)  There  was  no  formal  notation  or  language  definition  for  DALIMS.  Separate 
STAN AGs13  describe  the  generic  message  structure  for  each  of  the  NATO  digital  data 
links,  and  this  syntax  differs  among  the  various  types  of  data  links.  ADatP-5  specified 
rules  for  the  definition  of  bit  fields;  it  also  specified  some  standard  bit  fields,  bit-field 
fillers,  and  required  indices  and  cross-references  for  the  fields  that  were  used  in  DALIMS. 
Not  all  data  links  use  the  standard  bit  fields  that  were  provided  in  ADatP-5,  even  for  new 
development  (e.g.,  Link-11).14 

(U)  The  CEEL  ideal  concept  was  for  one  uniform  data  element  dictionary,  one 
abstract  syntax  for  both  character  and  bit-oriented  message  structures,  and  three  or  more 
different  sets  of  encoding  rules— one  for  character-oriented  systems,  one  for  Link- 1 1 
systems,  and  one  for  Link- 16  systems.  The  data  element  dictionary  was  to  be  converted 
from  its  current  form  to  a  more  structured  form  to  facilitate  (automatic)  verification  of  its 
completeness  and  integrity.  Alternates  considered  for  the  single  abstract  syntax  were 
FORMETS,  a  modified  version  of  FORMETS,  ASN.  1 15  (the  preferred  choice),  or  a  subset 
of  ASN.l.  More  than  one  set  of  encoding  rules  was  envisioned  because  the  single 
standard  set  of  encoding  rules  for  ASN.l  available  today16  dictates  the  inclusion  of  type 
and  length  information  for  each  field  and  subfield  each  time  a  message  is  passed,  whereas 
messages  for  current  NATO  data  links  contain  very  little  information  regarding  data  types 
and  field  lengths  (most  of  the  type  and  length  data  are  fixed  by  the  standard  for  the  data 
link)  to  improve  transmission  efficiency. 

(U)  ASN.l  was  the  preferred  choice  of  abstract  syntax  for  ADatP-3  because 

ASN.l: 

•  Supports  graphics  and  digitized  voice,  as  well  as  the  teletex  characters  that  are 
supported  by  FORMETS. 


13  (U)  For  example,  STANAGs  5501  (Link-1),  5503  (Link-3),  5504  (Link-4),  5507  (Link-7),  5510 
(Link-10),  5511  (Link-11),  5514  (Link-14),  and  5516  (Link  16). 

1 4  (U)  In  some  cases,  the  number  of  bits  per  field  had  been  decreased  in  order  to  optimize  bandwidth 
utilization  [Ref.  27], 

13  (U)  Abstract  Syntax  Notation  One,  ISO  8824  [Ref.  31]. 

1 6  (U)  Basic  Encoding  Rules  for  Abstract  Syntax  Notation  One,  ISO  8825  [Ref.  32]. 


26 

UNCLASSIFIED 


UNCLASSIFIED 


•  A  full  ASN.  1  implementation  would  facilitate  the  use  of  commercially  available 
products  [since  ASN.  1  is  the  only  approved  ISO  standard  for  open  systems 
interconnec  tion  (OS  I)] . 

•  ASN.l  has  all  the  power  of  data  representation  provided  by  FORMETS  and 
greater  flexibility  in  its  structuring  mechanism. 

•  The  encoding  rules  are  explicit  and  separately  defined  in  ISO  standards  [the 
X.409  standard  of  the  International  Telegraph  and  Telephone  Consultative 
Committee  (CCITT)  for  abstract  syntax  is  the  same  as  ASN.l,  but  the 
encoding  rules  are  included  in  the  same  standard]. 

•  ASN.  1  does  not  have  input/output  device-dependent  limitations  of  FORMETS 
(e.g.,  separate  lines  may  not  exceed  69  characters,  a  field  may  not  span  a  line, 
the  group  of  fields  in  a  columnar  set  may  not  exceed  69  characters);  where 
such  limitations  are  desired,  they  can  be  defined  and  enforced  using  data  types. 

The  primary  operational  objection  to  ASN.l  encoding  rules  was  that  encoded  ASN.l 
messages  are  not  human-readable.  A  review  of  this  concern  may  soon  take  place. 

5.3  Common  Information  Exchange  Glossary  (CIEG) 

(U)  The  Common  Information  Exchange  Glossary  (CIEG)  has  been  an  ADSIA 
initiative  to  harmonize  the  definitions  of  terms  used  in  the  data  element  dictionaries  of 
character-  and  bit-oriented  (data  link)  messages.  The  need  for  such  a  common  operational 
vocabulary  was  agreed  to  early  in  1986  [Ref.  33],  and  the  initial  CIEG  was  produced  six 
months  later,  based  on  STANAG  5511  (Link- 11),  STANAG  5516  (Link- 16),  and  ADatP- 
3  (FORMETS).  It  included  1,176  items,  one  third  without  a  definition  and  44  with  more 
than  one  definition  [Ref.  34].  The  CIEG  is  envisioned  to  contain  terms  and  definitions 
applicable  to  both  bit-  and  character-oriented  systems  [Ref.  35].  At  one  time,  the  CIEG 
was  envisioned  to  be  published  and  released  by  NATO's  Military  Agency  for 
Standardization  (MAS)  as  a  separate  document,  namely  AAP-25  (STANAG  5650) 
[Ref.  36].  Alternatively,  it  is  possible  that  the  work  on  the  CIEG  could  be  released  as  part 
of  AAP-6. 

(U)  At  a  minimum,  each  entry  in  the  Glossary  will  have  a  term,  the  agreed 
definition,  and  a  reference  to  the  context  in  which  it  is  used.  In  addition,  provision  is  made 
in  the  database  for  the  GLOT  to  record  source,  reference  number,  broader  term,  narrower 
term,  related  term,  synonym,  non-peer  synonym,  status,  and  rationale. 

(U)  The  Glossary  will  consist  only  of  "operational"  terms  that  "describe  one  or 
more  parts  of  a  function,  or  the  subject(s)  of  that  function  in  an  operational  activity." 
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Harmonization  will  be  performed  to  ensure  that  each  term  relates  (uniquely)  to  one 
definition,  in  the  same  context,  irrespective  of  the  community  in  which  it  is  used.  Multiple 
terms  for  the  same  object  or  activity  will  be  harmonized.  Units  of  measurement  will  be 
used  only  when  necessary  for  an  unambiguous  definition,  and  acronyms  will  not  be  used, 
in  principle,  in  the  definitions. 

(U)  The  Glossary  should  serve  a  number  of  purposes:  • 

•  Newcomers  to  the  operational  community  who  are  supported  by  information 
systems  will  find  the  meaning  and  relationships  of  operational  terms  used  in 
the  information  exchange  to  be  common  and  preserved. 

•  Trained  personnel  will  be  able  to  check  the  meaning  of  an  uncommon  term  or  • 

the  meaning  of  a  common  term  in  an  unusual  context. 

•  ADSIA  Working  Groups  will  use  the  GLOT  as  a  basis  for  procedural 
interoperability  standardization. 

•  Common  bit  fields,  representational  terms,  and  conversion  of  terms  based  on  • 

the  GLOT  will  be  investigated  for  use  in  development  of  future  data  links  and 

for  consideration  in  the  upgrade  of  existing  systems  [Ref.  36]. 
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6.  NAMING  CONVENTION 

(U)  This  section  proposes  a  convention  that  can  be  used  as  a  basis  for  naming 
generic  elements  and  data  elements  in  a  structured  manner.  Such  a  convention  is  needed  to 
ensure  that  those  data  elements  that  are  standardized  are  not  duplicates  of  other  data 
elements  and  accurately  reflect  the  intended  data  representation.  The  convention  consists  of 
syntax  and  a  set  of  rules,  both  based  on  four  types  of  words  to  be  used  in  the  names. 

6.1  Introduction 

(U)  The  purpose  for  using  a  naming  convention  is  to  provide  a  structured  method 
by  which  standard  names  for  generic  elements  and  data  elements  can  be  developed.  In  this 
way,  names  developed  in  separate  locations  stand  a  good  probability  of  having  the  same 
name  or  at  least  one  that  is  very  similar.  This  is  necessary  to  eliminate  the  creation  of 
duplicate  data  element  standards  (based  on  name)  that  have  been  developed  for  a  single  data 
concept.  A  naming  convention  or  structured  approach  is  needed  to  support  the 
development  of  names  to  achieve  this  goal.  Historically,  the  use  of  free-text  name 
development  has  lead  to  multiple  data  element  standards  for  a  single  concept.  Without  the 
control  exercised  through  a  naming  convention,  this  trend  will  continue.  The  naming 
convention  should,  in  addition  to  being  a  structured  approach,  result  in  a  name  that  is 
pseudo-readable  to  the  user.  This  means  that  even  though  the  name  conforms  to  a 
convention  and  may  suffer  some  awkwardness  in  word  flow,  it  must  be  readable  to  the 
user.  The  user  must  be  able  to  derive  the  basic  meaning  of  the  data  element  by  looking  at 
the  name.  This  type  of  feature  is  necessary  to  facilitate  the  use  of  data  element  standards 
for  their  intended  purpose-the  support  of  communication  and  interoperability. 

(U)  The  proposed  convention  is  based  on  standards  emerging  from  the  National 
Institute  of  Standards  and  Technology  (NIST)  [Ref.  19]  that  are  expected  to  be  offered  to 
ISO  in  the  near  future.  These  conventions  differ  in  many  respects  with  the  "OF-Language" 
convention  recommended  by  SHAPE  for  data  management  and  for  use  in  ACE  ACCIS 
[Ref.  5,  6].  The  conventions  recommended  here  are  richer  and  are  not  based  on  a 
proprietary  standard.  The  "OF-Language"  alternative  is  discussed  at  the  end  of  this 
Chapter  and  in  Appendix  D. 

(U)  Some  of  the  guiding  principles  to  be  followed  when  naming  conventions  are 
developed  and  evaluated  for  adoption  are  [Ref.  19]: 
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•  Clarity.  Names  are  as  clear  and  readable  as  possible.  Ideally,  they  are 
immediately  obvious  to  the  casual  user. 

•  Brevity  within  uniqueness.  Names  are  as  short  as  possible  while  still  retaining 
meaning  and  uniqueness  within  the  CCIS  data  structures  (e.g.,  database). 
Conflicts  between  brevity  and  clarity  are  resolved  in  favor  of  clarity. 

•  Conformance  to  rules  of  syntax.  Each  name  is  in  the  proper  format.  Waivers, 
if  granted,  are  used  sparingly.  The  degree  of  specificity  of  format  rules  will 
drive  the  frequency  of  waiver  requests. 

•  Context-freedom.  Each  entity  is  considered  discretely  from  all  others.  The 
name  references  the  logical  structure,  but  is  as  independent  as  possible  from 
the  physical  structure  of  the  data  and  from  other  data  entities.  For  example,  the 
name  of  a  data  element  derived  from  a  report  does  not  contain  the  name  of  or 
reference  to  the  report  Relationships  and  other  information  documented  in  the 
data  dictionary  for  an  entry  are  not  part  of  the  name. 

6.2  Definitions 

(U)  The  are  four  types  of  words  used  in  the  structured  naming  of  generic  elements 
and  data  elements.  These  are  defined  below: 

•  Class  Word  (CW).  A  word  used  to  specify  the  type  of  information  contained 
in  a  set  of  data  values. 

•  Modifier  (M).  A  word  that  helps  to  refine,  describe,  or  render  a  name  unique 
for  a  data  element,  which  is  not  designated  a  prime  or  class  word.  An 
architectural  modifier  (AM)  is  a  special  type  of  modifier  for  data  elements  that 
provides  the  logical  connection  between  the  data  element  and  an  organization's 
data  architecture  or  data  model. 

•  Prime  Word  (PW).  A  word  used  in  a  data  element  name  that  represents  the 
data  grouping  to  which  the  data  element  belongs. 

•  Qualifier  (Q).  A  word  used  with  a  class  word  to  further  describe  a 
characteristic  of  the  information  within  a  common  set  of  data  values. 

6.3  Syntax  for  Naming  Convention 

(U)  Structured  names  are  needed  for  both  generic  elements  and  data  elements.  The 
syntax  recommended  in  this  Working  Paper  and  described  in  this  chapter  is  based  on  the 
U.  S.  National  Institute  of  Standards  and  Technology  (NIST)  Special  Publication  500-149 
[Ref.  19].  The  general  syntax  of  the  data  element  name  is  as  follows: 

M:PW:M:CW:Q 
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where  M  represents  a  modifier,  PW  represents  a  prime  word,  CW  represents  a  class  word, 
and  Q  represents  a  qualifier.  Section  6.6  explains  this  naming  convention  in  more  detail, 
including  the  restrictions  and  numbers  of  each  type  of  word  that  is  permitted. 

(U)  The  next  two  sections  show  how  this  syntax  can  be  used  to  support  the 
structure  of  generic  elements  and  data  elements  with  names  that  conform  to  the  needs  of  an 
effective  data  management  and  standardization  program. 

6.4  Generic  Element  Name 

(U)  Each  data  element  consists  of  the  following:  a  structured  name;  information 
about  administrative  aspects  of  the  element;  a  set  of  data  values  and  structural  information; 
and  information  about  the  element's  relationships  to  other  objects.  A  data  element  name  is 
assigned  organizational  context  through  the  use  of  a  prime  word  and  some  modification 
words.  The  grouping  of  words  is  called  a  prime  term  and  is  discussed  in  Section  6.5. 

(U)  A  structured  name  is  given  to  a  generic  element  based  on  a  class  word  that 
represents  a  logical  grouping  of  data  values.  The  generic  element  name  should  accurately 
reflect  the  intent  of  a  data  value  set  and  its  associated  structure.  The  generic  element  name 
further  identifies  the  set  of  values  that  can  be  attached  to  a  data  element  as  in  the  case  of  a 
specific  set  (i.e.,  as  in  the  country  code  example).  Its  name  consists  of  an  optional 
modifier,  a  class  word,  and  up  to  two  optional  qualifiers.  The  general  format  is: 

GENERIC  ELEMENT  NAME  =  (Modifier)  +  Class  Word  +  (2)  QuaUfier(s) 

=  M :  CW  :  Q 

(U)  Figure  4  illustrates  the  structure  of  the  generic  element  name.  The  following 
are  examples  of  generic  element  names:  DATE;  DATE-TIME-GROUP;  NAME. 
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Figure  4.  (U)  Generic  Element  Name 

6.5  Data  Element  Name 

(U)  The  structured  name  of  a  data  element  is  composed  of  two  components:  a 
prime  term  and  a  generic  element  name.  The  prime  term  is  composed  of  a  prime  word  that 
may  be  further  modified  to  construct  a  name  that  is  representative  of  "what"  the  data 
element  is  purported  to  represent.  Composition  of  the  name  takes  the  general  format: 

DATA  ELEMENT  NAME  =  AM :  M  :  PW  :  M  :  CW  :  Q,  where 
PRIME  TERM  =  AM :  M :  PW :  M 
GENERIC  ELEMENT  NAME  =  M  :  CW  :  Q 

AM  =  Architectural  Modifier-one  required 

M  =  Optional  Modifier(s)-  maximum  of  four  in  the  Prime  Term  and  one 

in  the  Generic  Element  Name 

PW  =  Prime  Word-one  required 

CW  =  Class  Word-one  required 

Q  =  Optional  Class  Word  Qualifier(s)— maximum  of  two. 

(U)  Figure  5  illustrates  the  structure  of  a  data  element  name.  An  example  of  a  data 
element  name  conforming  to  these  conventions  is:17 


1 7  (U)  This  example  was  taken  from  STANAG  5621,  Appendix  3  to  Annex  A;  however,  most  of  the  data 
element  names  cited  in  STANAG  5621  do  not  follow  the  conventions  cited  in  this  section. 
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A  Prime  Word  (PW) 

Is  designated  In 
one  of  the  modifier 
positions. 

*  The  Architecture  Modifier  may  also  be  the  Prime  Word. 

RPW-2-1-8M 
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Figure  5.  (U)  Data  Element  Name 

ALLIED  COMMAND  EUROPE  UNIT  IDENTIFICATION  CODE 

(U)  A  prime  term  (e.g.,  ALLIED  COMMAND  EUROPE  UNIT 
IDENTIFICATION)  identifies  and  represents  the  object  or  relationship  between  objects 
about  which  a  organization  wishes  to  maintain  information.  It  has  the  form: 
AM:M:PW:M.  Here,  "ALLIED"  is  the  architectural  modifier,  "COMMAND"  and 
"EUROPE"  are  modifiers,  "UNIT  is  the  prime  word,  and  "Identification"  is  a  modifier.  In 
general,  an  object  is  represented  by  a  prime  word,  preceded  by  one  architectural  modifier 
and  optional  modifiers,  and  followed  by  additional  optional  modifiers  that  further  define 
what  the  object  is  in  relation  to  the  organization.  In  the  prime  term: 

•  The  prime  word  (e.g.,  UNIT)  should  be  positioned  in  front  of  the  class  word 
(i.e.,  in  front  of  the  generic  element  name)  and  within  the  prime  term. 

•  The  architectural  modifier  (e.g.,  ALLIED)  provides  the  logical  connection 
between  the  data  element  and  an  organization’s  data  architecture  or  data  model. 
The  architectural  modifier  should  be  the  first  word  in  the  data  element  name 
and  may  also  serve  as  the  prime  word  for  the  data  element  name  if  so  desired. 
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Architectural  modifiers  should  appear  on  the  prime  word  list;  however,  not  all 
prime  words  are  architectural  modifiers. 

(U)  The  generic  element  name  (e.g.,  CODE)  identifies  a  grouping  of  similar  data 
values,  which  has  been  classified  for  use  with  a  data  element 

6.6  Rules  for  Naming  Convention 

(U)  The  naming  rules  apply  to  the  construction  of  standard  element  (generic 
element  or  data  element)  names  for  CCIS  information  exchange  requirements.  The  rules 
should  also  be  applied  to  reconstruction  of  names  of  existing  data  elements  for  registration 
in  an  appropriate  repository  or  encyclopedia.  A  restructured  existing  data  element  name  not 
registered  as  an  approved  CCIS  data  element  should  be  carried  as  an  alias.  Thus,  when 
information  sharing  and  compatibility  are  required  across  two  or  more  CCISs,  data  element 
names  will  adhere  to  the  same  principles  and  structural  rules.  In  this  way,  common  data 
elements  can  be  identified.  There  should  be  no  alteration  to  the  principles  and  structural 
rules  that  are  adopted,  so  that  a  high  degree  of  standardization  can  be  achieved  and  data 
redundancy  can  be  eliminated. 

(U)  The  following  rules  apply  to  the  naming  and  formulation  of  generic  element  or 
data  element  names: 

•  Rule  1 :  Each  generic  element  name  will  contain  one  and  only  one  class  word. 

Comment:  By  restricting  the  generic  element  name  to  one  class  word, 
the  standard  element  is  formulated  to  describe  only  one  type  of 
information  collected  about  an  object 

•  Rule  2:  Class  words  will  be  reserved  (i.e.,  they  will  not  be  used  as  modifiers, 
qualifiers,  or  prime  terms). 

•  Rule  3:  Each  data  element  name  will  contain  one  prime  word  and  describe  only 
one  concept 

Comment:  By  requiring  a  data  element  name  to  have  one  prime  word, 
the  data  element  is  formulated  to  explicitly  describe  only  one  concept. 

•  Rule  4:  The  sequence  of  words  in  a  data  element  name  will  be  in  the  following 
format:  Modifier(s)  (if  required),  Prime  Word,  Modifier(s)  (if  required).  Class 
Word,  Qualifiers)  (if  required). 

Comment:  Optionally,  a  class  of  modifiers,  called  architectural 
modifiers,  may  be  defined  to  provide  a  logical  connection  between  a 
data  element  and  a  data  or  information  model.  When  used,  these  must 
be  the  first  modifier  in  the  prime  term. 

•  Rule  5:  Each  data  element  name  will  include  its  related  generic  element  name. 
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Rule  6:  Plurals  of  class  words  or  prime  words  are  not  permitted. 

Comment:  Removing  plurals  from  data  element  names  encourages  the 
designer  to  think  in  terms  of  primitive  concepts  and  increases  the 
possibility  that  two  people  will  develop  the  same  name  to  describe 
identical  concepts. 

Rule  7:  Modifiers  and  qualifiers  will  be  used  to  fully  describe  a  standard 
element  (five  modifiers  per  prime  word  and  one  modifier  plus  two  qualifiers 
per  class  word). 

Comment:  An  architectural  modifier  is  counted  as  one  of  the  modifiers 
for  the  prime  term. 

Rule  8:  Word  order  of  commonly  used  terms  will  be  preserved  in  data  element 
alias  names  (e.g.,  Port  of  Debarkation,  Ministry  of  Defence). 

Rule  9:  A  unit  of  measure  suffix  will  be  applied  to  the  names  of  all  elements 
that  describe  a  numeric  quantity  (e.g.,  Volume-in-Litres). 

Rule  10:  No  abbreviations  or  acronyms  are  permitted  in  a  standard  element 
name. 


Comment:  Abbreviations  and  acronyms  detract  from  the  clarity  of  a 
standard  element  name. 

Rule  1 1 :  Only  alphabetic  characters  (A-Z,  a-z)  are  permitted  in  a  standard 
element  name  with  two  exceptions. 

(1)  A  hyphen  may  be  used  to  connect  the  words  in  a  prime  term  or  generic 
element  name. 

(2)  A  number  may  be  used  when  it  is  part  of  a  descriptive  name  (e.g., 
M109A3  Howitzer). 

Comment:  By  permitting  only  alphabetic  characters,  standard  element 
developers  are  encouraged  to  describe  standard  element  names  in  terms 
of  what  the  data  is  and  not  how  it  is  stored  or  used.  This  rule  also 
improves  the  probability  that  different  people  will  develop  the  same 
namr  for  identical  standard  elements. 

Rule  12:  Names  of  organization,  computer,  or  information  systems, 
directives,  forms,  screens,  or  reports  are  not  permitted  in  standard  element 
names. 

Rule  13:  Titles  of  blocks,  rows,  or  columns  of  screens,  reports,  or  listings  are 
not  permitted  in  standard  element  names  unless  those  titles  satisfy  Rules  1-11. 
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6.7  Relation  of  Recommended  Naming  Convention  to  Other 
Standards 

(U)  The  Information  Resource  Dictionary  System  (IRDS)  [Ref.  37]  is  an  emerging 
standard  for  formally  describing  data.  The  structure  for  assigning  names  in  IRDS  provides 
for  three  different  kinds  of  names  for  data  entities,  and  the  convention  recommended  for 
ATCCIS  is  consistent  with  IRDS.  The  IRDS  structure  supports: 

•  A  single  Access-Name,  serving  as  the  primary,  unique  identifier  of  the  data 
entity.  A  data  dictionary  entity  has  only  one  Access-Name.  The  convention 
recommended  in  this  Working  Paper  for  ATCCIS  provides  for  the  Access- 
Name  as  an  attribute  of  each  data  element,  "INFORMATION  DATA 
ELEMENT  MNEMONIC  ABBREVIATION"  (see  Appendix  E,  Section  2.1). 

•  An  optional  Descriptive-Name,  normally  longer  and  serving  the  same  function 
as  the  Access-Name.  The  Descriptive-Name  corresponds  to  the  data  element 
name  defined  in  this  Chapter  for  ATCCIS. 

•  Optional  Alternate-Names,  providing  functional  attributes  of  the  entity;  they  are 
not  unique  and  serve  as  aliases.  The  concept  of  data  element  alias  provides  this 
function  in  the  convention  recommended  for  ATCCIS. 

(U)  Several  options  are  defined  in  the  NIST  recommendation  [Ref.  19,  Section 
5.1]  for  naming  conventions.  Two  of  these  options  are  included  in  the  convention 
described  in  this  chapter  and  recommended  for  ATCCIS.  The  remaining  option  was 
omitted,  since  it  puts  both  the  class  word  and  prime  word  as  the  the  leading  terms  for  a  data 
element  and  is  therefore  the  least  readable  of  the  three  options.  Note  that  NIST  convention 
applies  to  the  term  "Access-Name”;  this  convention  has  been  extended  and  applied  to  both 
generic  elements  and  data  elements. 

(U)  In  its  discussion  of  data  terminology,18  AM  96-1-4  discusses  only  one  naming 
convention,  the  so-called  "OF-Language,"  and  recommends  it  for  adaption,  as  appropriate, 
in  ACE.  Appendix  D  contains  a  short  description  and  some  examples  for  the  use  of  the 
"OF-Language"  naming  convention. 

(U)  The  use  of  the  "OF-Language"  naming  conventions  to  support  the  naming  of 
data  elements  has  three  major  faults.  These  restrictions  render  its  use  undesirable.  These 
faults  are: 


1 8  (U)  "Data Terminology,"  Annex  A,  AM  96-1-4  [Ref.  6],  Section  l.L. 
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First,  the  "OF-Language"  is  based  on  the  premise  that  standardization  is  to  be 
accomplished  on  the  use  of  data  elements  vice  the  structure  of  the  data  element. 
In  previous  discussions  it  has  been  shown  that  standardization  based  on  use  is 
counterproductive  to  the  aim  of  interoperability.  The  synonymic  and 
homonymic  issues  that  arise  based  on  data  usage,  create  a  potential  redundancy 
and  incompatibility  of  data  that  will  not  support  the  relatively  free  flow  of 
information  implied  in  the  NIPD  definition  of  Degree  5  or  6  interoperability. 

Second,  the  "OF-Language"  is  a  psuedo-symbolic  representation  for  a  data 
element  name.  This  makes  the  syntax  difficult  for  the  average  user  to  read  and 
comprehend.  The  more  text  oriented  the  name  development,  the  greater  is  the 
potential  for  successful  implementation.  Data  standardization  for 
interoperability,  or  any  purpose  for  that  matter,  must  be  functionally  based. 
This  means  the  functional  experts  must  decide  on  the  material  content  and 
naming  of  the  data  elements.  Only  in  this  way  will  the  required  meaning  be 
placed  in  the  correct  context  to  support  efficient  and  effective  use  of 
Information  Exchange  Requirements. 

Lastly,  the  "OF-Language"  is  perceived  as  a  proprietary-based  convention  due 
to  its  conceptualization  and  development  by  the  IBM  Corporation  to  support 
IBM  hardware.  This  proprietary  aspect  of  the  language  makes  it  highly 
suspect  in  an  ATCCIS  environment  that  is  seeking  to  identify  and  develop  non- 
proprietary  standards  to  answer  near-term  and  future  command  and  control 
issues. 


37 

UNCLASSIFIED 


UNCLASSIFIED 


(This  page  intentionally  left  blank.) 


38 

UNCLASSIFIED 


UNCLASSIFIED 


7.  ATTRIBUTE  LIST 

(U)  As  discussed  earlier  in  the  paper,  within  the  concept  of  data,  each  of  the  three 
elements  identified  to  support  data  management-generic  element,  data  element,  and  data 
element  alias-is  a  collection  of  attributes.  These  attributes  qualify  or  characterize  the 
distinct  features  of  each  element  In  order  to  achieve  data  management  in  the  environment, 
a  set  of  attributes  will  have  to  be  selected  as  a  minimum  set,  on  which  to  base  such 
activities.  This  selected  set  will  enable  the  operators  of  ATCCIS  conformant  systems  to 
collectively  identify,  store,  communicate,  and  manipulate  data  from  a  common  point  of 
reference.  This  does  not  imply  that  the  physical  storage  in  national  systems  will  have  to 
change  based  on  these  attributes;  rather,  to  facilitate  the  communication  of  EERs  (from  the 
data  element  perspective),  a  common  point  of  reference  must  be  established. 

(U)  The  attribute  list  provided  in  Appendix  E  has  been  prepared  as  a  suggested 
starting  set.  Each  attribute  has  been  named  in  accordance  with  the  naming  conventions 
proposed  earlier  in  the  paper  and  is  accompanied  by  a  definition.  To  achieve  data 
management,  such  a  list  will  have  to  be  compiled,  along  with  definitions  and  more  technical 
details  of  what  the  physical  manifestation  of  each  attribute  will  look  like  for  storage 
purposes. 

(U)  The  attributes  have  been  broken  down  by  element  and,  within  each  element,  by 
those  that  are  administrative,  relational,  and  representational.  See  Appendix  E  for  the 
listing. 
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8.  DATA  MANAGEMENT  POLICY  AND  PROCEDURES 

(U)  This  is  a  proposal  for  addressing  the  requirements  in  CCIS  data  management  in 
the  area  of  policy  and  procedures. 

8.1  Introduction 

(U)  This  chapter  contains  an  approach  for  the  procedural  standards  for  CCIS  data 
management,  including  development,  documentation,  review,  approval,  implementation, 
and  archiving  for  generic  elements,  data  elements,  and  data  element  aliases.  The  term 
"standard  element"  is  used  when  more  of  these  three  types  of  elements  is  being  referenced 
and  to  simplify  discussion. 

(U)  ACE  Manual  96-1-4  describes  in  some  detail  the  responsibilities  of  CCIS  data 
administrators  and  database  administrators.  The  other  personnel  referenced  below  are: 
information  class  proponent,  data  encyclopedia  administrator,  standard  element  developer, 
and  ACE  (ATCCIS)  data  manager.  The  roles  of  these  personnel  are  described  in  the 
sections  that  follow. 

8.2  Standardization  Procedures  for  Data  Elements  and  Other 

Standard  Elements 

8.2.1  Identifying  Data  Element  Requirements 

(U)  Data  elements  and  other  standard  elements  required  to  support  CCIS 
applications  are  identified  during  the  life  cycle  phases  of  an  information  system.  The 
identification  of  standard  elements  should  be  done  in  the  early  phases  of  a  system's  life 
cycle.  The  system  developer  or  the  system's  functional  proponent  should  compare  these 
standard  elements  to  existing  standard  elements  in  a  CCIS  data  encyclopedia  to  determine  if 
existing  standard  elements  can  satisfy  the  data  requirement  of  the  application.  When 
standard  elements  are  found  that  meet  the  requirement,  documentation  from  the 
encyclopedia  should  be  incorporated  into  systems  design  documentation  (e.g.,  data 
requirements  document).  If  no  standard  element  is  found  or  a  change  is  required  to  an 
existing  standard  element,  the  standardization  process  must  be  initiated. 

8.2.2  Data  Standards  Considerations  for  Information  Systems 

(U)  The  following  considerations  apply  throughout  the  life  cycle  of  any 
information  system: 
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(1)  Data  Documentation.  A  CCIS  data  encyclopedia  should  be  used  as  a  source 
for  producing  data  documentation  for  information  system  design  documents. 
Using  a  CCIS  data  encyclopedia  ensures  that  data  documentation  remains 
consistent  CCIS-wide  in  whatever  information  system  it  may  be  used. 

(2)  Reviews.  Organizational  data  administrators  should  participate  in  design 
reviews,  technical  walkthroughs,  and  CCIS  design  tests  to  ensure  that  standard 
elements  are  actually  being  incorporated  into  the  technical  design. 
Organizational  data  administrators  and  database  administrators  will  participate 
in  software  qualifications  tests  to  ensure  that  data  standards  are  being  used  as 
intended. 

(3)  Application  Program  Development  Support.  Organizational  data  administrators 
and  database  administrators  should  provide  documentation  and  advisory 
services  that  assist  with  software  development  efforts  to  ensure  that  data  are 
independent  of  the  application  programs  being  developed.  Specifically, 
organizational  level  data  administrators  and  organizational  level  database 
administrators  should: 

(a)  Support  the  development  effort  by  using  a  CCIS  data  encyclopedia  to 
locate  or  generate  standard  elements  for  use  in  command  and  control 
information  systems. 

(b)  Encourage  system  developers  to  use  data  starvation  techniques  to  delay 
binding  time19  between  application  program  and  databases.  Data 
starvation  is  the  avoidance  of  explicitly  declaring  data  structure  definitions 
within  the  application  program.  The  program  is  coded  to  rely  on 
dictionary  look-ups  at  execution  time.  The  longer  the  binding  time  is 
delayed,  the  more  predisposed  the  software  will  be  to  adapt  to  changes  in 
the  data. 

(c)  Assist  standard  element  developers  in  installing  standard  elements, 
element  changes,  and  version  updates. 

(d)  Use  a  CCIS  data  encyclopedia  to  manage  change  and  version  updates,  as 
well  as  make  new  data  representations  available  to  users,  in  support  of 
application  program  testing. 


19  (U)  In  this  context,  binding  time  refers  to  the  time  in  the  system  development  process  that  the  system 
designers  are  provided  detailed  information  about  the  databases  to  be  incorporated  into  the  system. 

Until  the  binding  time  is  reached,  the  developer  must  retain  a  high  degree  of  independence  between  the  0 

application  software  and  the  attributes  of  the  data  to  be  used. 
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8.2.3  Status  of  Standard  Elements 

(U)  Each  standard  element  will  have  a  standardization  status:  candidate  element, 
approved  element,  installed  element,  or  archived  element.  Each  status  marks  the  progress 
of  the  element  through  the  data  standardization  process.  The  possible  standardization  status 
states  for  a  standard  element  are: 

(1)  Candidate  Element.  This  is  the  status  assigned  to  a  data  requirement  that  has 
been  identified,  defined,  and  submitted  to  the  appropriate  organizational  data 
administrator  for  review.  A  candidate  element  can  include  a  generic  element,  a 
data  element,  a  data  element  alias,  or  a  change  to  an  existing  standard  element. 

(2)  Approved  Element.  Candidate  elements  that  have  passed  functional  and 
technical  reviews  are  upgraded  to  approved  elements.  Data  values  based  on 
approved  elements  may  be  used  for  development.  The  Information  Class 
Proponent  must  assign  and  coordinate  organizations  authorized  to  supply  data 
values,  define  access  requirements,  and  specify  a  CCIS-wide  installation  date 
for  each  approved  element.  Once  data  elements  have  an  installation  date,  there 
can  be  no  further  changes  to  the  element. 

(3)  Installed  Element.  On  the  assigned  installation  date,  an  approved  element  is 
upgraded  to  an  installed  element.  Databases  will  have  been  modified  to 
accommodate  the  actual  data  values  based  on  the  newly  installed  element,  and 
affected  information  systems  must  then  operate  using  updated  versions  of  the 
databases.  Organizations  authorized  to  supply  data  values  will  commence  then- 
responsibilities  for  entering  and  maintaining  the  data  in  the  databases  required 
to  run  in  accordance  with  the  installed  element.  After  the  installation  date  is 
assigned,  the  standard  element  will  be  used. 

(4)  Archived  Element.  Installed  elements  become  archived  elements  when  they  no 
longer  support  a  data  requirement.  The  archived  element  and  its  associated 
attributes  will  be  retained  in  the  CCIS  data  encyclopedia  for  a  period  of  time 
required  by  NATO  policy  or  as  established  by  the  CCIS  data  encyclopedia 
administrator.  These  retained  standard  elements  will  be  used  to  assist  with 
compiling  or  recovering  information  that  spans  several  versions  of  the  CCIS 
data  encyclopedia. 

(5)  Non-Standard  Element.  Those  information  systems  and  application  programs 
not  using  standard  elements  will  bear  the  cost  of  data  conversion  for  any 
necessary  transmittal  to  standard  information  systems  and  databases.  Systems 
using  non-standard  elements  must  be  modified  or  bridged  to  the  standard.  The 
non-standard  element  will  be  registered  in  the  CCIS  data  encyclopedia  as  an 
alias  to  the  appropriate  current  standard  element 
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8.3  Life  Cycle  for  Standard  Elements 

(U)  To  control  standard  elements,  organizational  data  administrators  must  actively 
incorporate  the  disciplines  of  life  cycle  management.  The  standard  element  life  cycle 
reflects  four  phases  necessary  to  define,  approve,  implement,  assess,  and  review  standard 
elements. 


8.3.1  Phase  1— Element  Requirements  Definition 

(U)  Detailed  data  requirements  definition  occurs  during  the  definition  and  design 
phases  for  information  systems  development  life  cycle.  The  following  are  the  major 
activities  for  Phase  1: 

(1)  Standard  Element  Development.  If  a  standard  element  does  not  exist,  the 
required  set  of  attributes  for  the  new  element  must  be  documented  and 
submitted  for  standardization  to  the  information  class  proponent.  The 
organization-d  data  administrator  assists  the  requirements  developer  in 
reviewing  the  current  inventory  of  CCIS  standard  elements  to  determine 
whether  or  not  a  standard  element  exists  that  suits  a  specific  information 
requirement.  In  order  to  determine  the  specific  set  of  attributes  to  document, 
standard  element  developers  must  consider  the  following  possibilities: 

(a)  For  a  candidate  generic  element:  When  the  data  requirement  cannot  be 
satisfied  by  an  existing  generic  element,  the  Standard  Element  Developer 
must  develop  a  candidate  generic  element  that  will  satisfy  the  requirement. 
A  candidate  generic  element  may  represent  a  change  to  an  existing  generic 
element  or  an  entirely  new  generic  element 

(b)  For  a  candidate  data  element.  After  searching  the  current  inventory  of 
CCIS  standard  elements  and  no  data  element  is  found  that  meets  a 
particular  information  requirement,  the  requirements  developer  must 
submit  documentation  for  a  candidate  data  element.  This  documentation 
will  contain  the  information  necessary  to  satisfy  the  attributes  for  the 
element. 

(2)  System  Control  Data.  Data  elements  will  not  be  standardized  if  they  are 
designed  only  to  make  system  inputs  or  outputs  more  appealing,  are  primarily 
syntax  or  semantics  related,  or  if  they  have  no  particular  significance  to  CCIS 
missions  and  goals.  Standard  element  developers  will  not  categorize  data 
elements  as  system  control  data  in  order  to  avoid  standardization  requirements. 

(3)  Candidate  Element  Documentation  Submission 

(a)  Organizational  data  administrators  will  review  standard  element 
documentation  from  requirements  developers  in  their  area  of  responsibility 
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and  in  accordance  with  guidance  from  their  chain  of  command.  These 
developers  will  submit  elements  for  coordination  and  review  in  order  to 
begin  the  review  and  approval  phase  (Phase  2).  At  this  time  the  status  of 
the  element  changes  from  proposed  to  candidate.  The  elements  are 
submitted  through  the  standard  element  approval  channel.  Review  is 
facilitated  by  use  of  a  CCIS  data  encyclopedia. 

(b)  To  ensure  expeditious  and  timely  approval  of  data  elements  for  use, 
candidate  elements  will  adhere  to  guidance  provided  ADSIA. 

8.3.2  Phase  2--Review  and  Approval  for  Candidate  Elements 

(U)  The  following  are  the  major  activities  for  Phase  2: 

(1)  Organizational  Data  Administrator  Review.  The  organizational  data 
administrators  will  review  the  documentation  submitted  on  candidate  elements 
to  ensure  that  the  documentation  meets  documentation  standards  prescribed  in 
ADSIA  guidance.  As  part  of  the  review  and  validation  process,  organizational 
data  administrators  will: 

(a)  Facilitate  the  coordination  of  candidate  elements  at  their  level  of  command 
to  ensure  proper  staffing  with  the  functional  and  technical  personnel  in 
their  area  of  responsibility.  The  CCIS  data  encyclopedia  administrator 
will  provide  advice  to  the  organizational  data  administrator  on  technical 
considerations  as  appropriate. 

(b)  Facilitate  the  coordination  of  candidate  elements  with  subject  matter 
experts  who  will  validate  the  functionality  of  the  candidate  standard 
element. 

(c)  Coordinate  with  the  likely  users  of  the  candidate  standard  element 

(d)  Compare  a  candidate  standard  element  to  existing  standard  elements  to 
ensure  it  does  not  already  exist. 

(e)  Review  the  collection  of  attributes  completed  by  the  requirements 
developer  to  confirm  the  completeness  of  the  information  submitted. 

(f)  Verify  that  the  candidate  element  is  assigned  to  the  appropriate  information 
class. 

(g)  Forward  recommended  candidate  element  to  the  NATO  Information  Class 
Proponent. 

(2)  NATO  Information  Class  Proponent  functional  Review: 

(a)  The  NATO  Information  Class  Proponent  should  ensure  consistency  of 
elements  among  related  development  projects  and  with  existing  standard 
elements.  This  includes  resolving  differences  in  documentation  for  the 
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same  candidate  element  and  staffing  with  interested  users  the  positions 
taken. 

(b)  When  reviewing  candidate  standard  elements,  NATO  Information  Class 
Proponents  will  consider  STANAGs,  directives,  and  associated 
regulations,  along  with  security  classification  and  operational  security. 

(c)  To  effectively  eliminate  the  possibility  of  redundancy  or  inconsistency,  the 
NATO  information  class  proponent  will  ensure  that  naming  conventions 
as  prescribed  in  Chapter  6  are  properly  applied.  Each  data  definition 
describes  what  the  data  element  is,  represents  only  one  concept,  and 
supports  both  the  element  name  and  the  set  of  data  values.  The  NATO 
information  class  proponent  will  coordinate  with  the  CCIS  data 
encyclopedia  administrator  to  receive  and  resolve  the  results  of  the 
technical  review. 

(d)  To  ensure  that  candidate  standard  elements  support  the  CCIS  missions 
and  goals  and  that  they  are  more  generally  applicable  across  the  CCISs, 
the  NATO  information  class  proponent  will  review  the  candidate  to: 

Verify  that  the  candidate  element  does  not  duplicate  an  existing 
standard  element. 

Verify  the  regulation,  publication,  bulletin,  or  other  document  that 
authorizes  use  of  the  candidate  standard  element,  when  applicable. 

Verify  that  the  candidate  standard  element  supports  information 
requirements  from  a  CCIS-wide  perspective. 

Determine  the  criteria  for  accessing  the  data.  Access  ranges  from 
"available  to  all"  to  "private."  Access  is  determined  by  NATO  or 
other  policy,  functional  need,  and  security  requirements. 

Designate  the  office(s)  or  person(s)  who  are  authorized  to  enter  data 
values  into  a  data  element  within  a  database  or  information  system. 

Designate  the  office  or  person  who  will  be  the  functional  expert  for 
defining,  reviewing,  and  updating  the  candidate  standard  element  and 
its  attributes. 

Determine  whether  the  requested  access  privilege  conflicts  with 
previously  established  access  privileges. 

Resolve  conflicts  in  usage  and  responsibility  where  necessary. 

CCIS  Data  Encyclopedia  Administrator  Technical  Review.  The  CCIS  data 
encyclopedia  administrator  will  conduct  a  concurrent  technical  review  of  the 
candidate  element  for  its  adherence  to  CCIS  policy  and  guidance.  This 
includes  such  considerations  as  reviewing  field  types  and  sizes;  the  CCIS-wide 
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impact  of  adopting  the  candidate  standard  element;  the  proper  use  of  naming 
conventions;  and  whether  the  candidate  standard  element  name  is  a  proper 
reflection  of  the  definition.  If  a  candidate  standard  element  fails  the  technical 
review,  the  encyclopedia  administrator  will  make  the  necessary 
recommendations  to  the  NATO  information  class  proponent  to  bring  the 
candidate  standard  element  into  technical  compliance.  As  a  minimum  the 
technical  review  will  look  at  the  following  aspects  of  the  candidate  element: 

(a)  Conformance  to  appropriate  provisions  of  NATO  and  other  applicable 
international  standards 

(b)  Proper  application  of  naming  conventions,  as  prescribed  in  Chapter  6 

(c)  Cohesive  data  definitions  (i.e.,  the  data  definition  does  not  represent  more 
than  one  concept  and  supports  both  the  standard  element  name  and  the  set 
of  data  values). 

(4)  NATO  Information  Class  Proponent  Approval.  The  NATO  information  class 
proponent  will  approve  or  disapprove  a  candidate  standard  element  pending  the 
final  technical  review  by  the  CCIS  encyclopedia  administrator.  If  the  candidate 
element  passes  the  reviews,  the  NATO  information  class  proponent  will 
approve  it  as  an  approved  standard  element. 

(5)  Adjudication.  The  ACE  (ATCCIS)  Data  Manager  resolves  disputes  among 
NATO  information  class  proponents  for  ATCCIS  and  the  CCIS  data 
encyclopedia  administrator  concerning  candidate  standard  element  approval, 
installation,  and  archiving.  When  other  resolution  efforts  fail  during  the 
review  and  approval  phase,  the  ACE  (ATCCIS)  Data  Manager  performs  the 
role  of  arbitrator.  The  ACE  (ATCCIS)  Data  Manager  will  review 
recommendations,  consider  any  grievances,  and  render  final  decisions. 

8.3.3  Phase  3-Implementation  of  Approved  Elements 

(U)  Once  candidate  standard  elements  become  approved  elements,  the  CCIS  data 
encyclopedia  administrator  will  identify  maintenance  that  needs  to  be  performed  on  existing 
data  structures  and  specify  how  updated  values  for  the  approved  standard  element  are  to  be 
distributed. 

(U)  In  those  CCIS  databases  and  information  systems  that  require  a  direct  data 
exchange,  an  installation  date  will  be  specified  for  each  approved  standard  element  This  is 
the  date  after  which  the  approved  standard  element  becomes  installed  and  use  of  a  standard 
element  is  mandatory  in  partitioned  and  replicated  databases,  applications,  and  reports.  It  is 
also  the  date  by  which  implemented  ATCCIS  conformant  databases  must  have  been 
changed  or  the  required  aliases  have  been  entered  into  the  encyclopedia.  Where  the  change 
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applies  to  a  manual  portion  of  a  CCIS  with  no  automated  interface,  the  new  standard 
element  will  be  phased  in  as  the  current  shelf  stock  of  forms  is  depleted.  Forms  will  be 
redesigned  to  use  the  installed  standard  element. 

8.3.4  Phase  4— Assessment  and  Review  of  Standard  Elements 

(U)  During  assessment,  organizational  data  administrators  will  conduct  audits  of 
data  being  maintained  in  databases  and  information  systems  to  ensure  data  quality  and  track 
the  usage  of  the  data  to  determine  whether  collection  and  maintenance  of  the  data  is 
considered  to  be  worth  the  cost.  Assessment  results  will  be  made  available  to  NATO 
information  class  proponents  and  users  for  use  in  performing  data  management 
responsibilities.  The  following  are  the  major  activities  for  Phase  4: 

(1)  Verification.  After  the  installation  date  of  an  approved  standard  element,  the 
CCIS  data  encyclopedia  administrator  will  verify  that  the  standard  element  has 
been  physically  added  to  the  databases  and  information  systems  that  are  new  or 
have  been  modified,  and  which  are  required  to  run  CCIS.  The  results  of  the 
installation  review  will  be  provided  to  the  system  development  team  involved. 
Problems  encountered  will  be  addressed  based  on  the  criticality  and  priority  of 
each  problem. 

(2)  Monitoring.  Organizational  data  administrators  will  maintain  an  ongoing  effort 
to  measure  and  evaluate  the  use  of  data  by  databases  and  ATCCIS 
Applications,  and  to  monitor  the  environmental  changes  affecting  performance. 
Measurements  established  for  those  standard  elements  of  the  databases 
required  to  run  the  CCIS  that  are  deemed  critical  (e.g.,  response  time,  line 
traffic,  mean  time-to-failure,  mean  time-to-recover,  adherence  to  procedures) 
will  be  monitored  and  evaluated  regularly,  and  historical  information  kept  so 
that  trends  can  be  observed  and,  whenever  possible,  problems  can  be  avoided 
or  minimized. 

(3)  Evaluation.  Organizational  data  administrators  will  determine  if  data  is  being 
exchanged  across  databases,  ATCCIS  Applications,  and  functional  lines. 
Projected  activity  in  databases  and  information  systems  will  be  compared  to 
actual  activity.  All  recovery,  security,  and  synchronization  procedures  and 
processes  will  be  monitored  to  ensure  that  they  actually  function  as  designed. 

(4)  Standard  Element  Archiving.  The  CCIS  data  encyclopedia  administrator 
recommends  to  the  ACE  (ATCCIS)  Data  Manager  the  archiving  of  any 
standard  element  that  is  no  longer  needed  and  whose  maintenance  and 
management  cost  may  exceed  its  utility.  Consideration  must  be  given  to  use  of 
the  standard  element  in  manual  systems,  forms,  reports,  messages,  and 
supporting  publications.  Standard  elements  nominated  and  approved  for 
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archiving  will  be  maintained  as  archived  standard  elements  in  the  CCIS  data 
encyclopedia  for  a  period  of  time  as  prescribed  by  NATO.  Recommendations 
for  archiving  will  follow  the  information  management  approval  channel  as 
specified  in  the  candidate  standard  element  approval  phase. 

8.4  Enforcement  of  Standard  Elements 

(U)  Standard  element  enforcement  procedures  should  be  worked  out  by  agreement 
within  the  NATO  nations.  The  exact  specification  of  these  procedures,  as  well  as  the 
policy  they  support,  are  the  responsibility  of  the  NATO  nations  that  participate  within 
ATCCIS.  However,  to  be  effective,  a  data  management  and  standardization  effort  must 
have  the  responsibility  and  authority  to  accomplish  the  task.  The  enforcement  of  standards 
is  critical  to  the  success  of  the  standardization  effort.  Due  to  the  sensitive  nature  of  these 
types  of  rule-penalty  relationships  and  their  importance,  none  will  be  proposed  here  and 
their  determination  will  be  left  to  the  appropriate  NATO  body. 

8.5  Exemptions  and  Waivers 

(U)  Exemptions  and  waivers  will  be  granted  only  in  exceptional  situations.  The 
overall  success  of  the  data  management  program  depends  on  how  effectively  these 
exemptions  and  waivers  are  handled.  Neither  exemptions  nor  waivers  will  be  granted  for 
new  databases  or  information  systems  merely  because  nonstandard  data  are  currently  being 
used  in  databases  and  information  systems  with  which  the  new  database  or  information 
system  must  interface.  Neither  exemptions  nor  waivers  are  permanent.  Procedures  for 
exemptions  and  waivers  are  as  follows: 

(1)  Exemptions  are  approved  where  compliance  with  a  standard  element  is  either 
impossible  or  extremely  impractical..  Exemptions  are  re-evaluated  by  the  ACE 
(ATCCIS)  Data  Manager  at  least  biannually. 

(2)  Waivers  are  approved  for  a  specific  period  of  time  and  are  automatically 
revoked  at  the  end  of  that  time  period.  The  maximum  time  period  that  can  be 
specified  for  a  waiver  is  90  days  (or  some  other  period  agreed  to).  Waivers 
may  be  granted  in  areas  where  previously  established  priorities  preclude 
compliance  with  a  standard  element  within  the  time  frame  specified. 

(3)  Requests  for  exemptions  and  waivers  will  be  submitted  in  writing  through  data 
management  channels  to  the  CCIS  data  encyclopedia  administrator  and  must 
contain  complete  supporting  information  that  will  assist  in  evaluating  requests. 
The  CCIS  data  encyclopedia  administrator  will  evaluate  the  request, 
recommend  to  the  ACE  (ATCCIS)  Data  Manager  approval  or  denial  of 
exemptions  and  waivers,  and  advise  the  requester  of  exemption  and  waiver 
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decisions.  Requests  for  back-to-back  waivers  will  be  forwarded  for  decision. 
The  written  request  must  contain  the  following  information: 

(a)  Type  of  request  (i.e.,  exemption  or  waiver) 

(b)  Name  of  the  CCIS  database  or  application  for  which  the  request  is  written 

(c)  Names  of  the  standard  elements  for  which  the  waiver  is  requested 

(d)  Names  of  the  nonstandard  elements  currently  being  used 

(e)  Reasons  for  not  implementing  the  standard  elements. 

(4)  The  CCIS  data  encyclopedia  administrator  will  maintain  records  to  identify  all 
exemption  and  waiver  requests  as  a  suspense  control  for  re-evaluating 
exemptions  and  assuring  that  compliance  with  standard  elements  is  achieved. 

(5)  Organizational  data  administrators  will  receive  a  copy  of  each  exemption  and 
waiver  granted. 
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9.  CONCLUSIONS  AND  RECOMMENDATIONS 

9.1  Conclusions 

(U)  The  conclusions  of  this  Working  Paper  are  as  follows: 

(1)  To  achieve  interoperability,  data  standardization  and  management  must  be 
accomplished  through  an  integrated  approach. 

(2)  Discussions  of  data  management  issues  have  not  led  to  a  NATO-wide  policy. 
A  data  management  policy  is  needed,  and  this  need  has  been  recognized  by 
ADSIA  and  other  NATO  bodies.  The  ISWG  has  been  asked  by  ADSIA  to 
provide  recommendations  on  data  management. 

(3)  A  NATO  glossary  of  military /operational  terms  is  needed  for  information 
exchange;  it  must  go  beyond  the  current  approach  being  used  in  the 
development  of  AAP-25. 

(4)  Development  of  standards  by  ISO/IEC  and  other  standards  bodies  for  data 
representation,  syntax,  encoding,  and  exchange  needs  to  be  monitored  by 
NATO  agencies.  Appropriate  bodies  of  TSGCEE,  ADSIA,  and  NACISA  need 
to  assess  how  well  the  civil  standards  meet  military  requirements  for  data 
management  and  agree  on  a  policy.  Further  analysis  and  a  decision  on 
message  syntax  requirements  and  standardization  options  (e.g.,  ASN.l, 
FORMETS)  is  needed. 

(5)  A  NATO  Data  Element  Naming  Convention  is  needed. 

(6)  A  NATO  Data  Element  Attribute  List  is  needed  to  characterize  the  distinct 
features  of  data  elements  and  other  data  concepts. 

(7)  The  NATO  data  management  policy  needs  to  be  applied  to  the  specification  of 
data  elements  to  be  used  for  developing  and  validating  IERs. 

9.2  Recommendations 

(U)  The  following  recommendations  are  provided  for  consideration  by  the 
appropriate  NATO  -  SHAPE  bodies: 

(1)  A  consistent  and  integrated  NATO- wide  data  management  policy  should  be 
developed,  approved,  and  promulgated  by  the  NACISC. 

(2)  The  nations,  NATO,  and  SHAPE  should  monitor  ISO/IEC  development  of 
standards  for  data  representation,  syntax,  encoding,  and  exchange. 
Appropriate  bodies  of  TSGCEE,  ADSIA,  and  NACISA  should  assess  how 
well  the  civil  standards  meet  military  requirements  for  data  management  and 
make  recommendations. 
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(3)  A  NATO-wide  glossary  of  military/operational  terms  should  be  developed. 
ACE,  the  other  Major  NATO  Commands  (MNCs),  and  the  nations  should 
press  urgently  for  an  authoritative  statement  by  NATO. 

(4)  A  NATO-wide  Data  Element  Naming  Convention  should  be  developed.  The 
naming  convention  provided  in  Chapter  6  of  this  Working  Paper  should  be 
adopted  as  a  starting  point  for  use  with  data  elements  and  other  data  concepts. 
It  should  be  modified  as  necessary  and  used  in  ACE  and  NATO. 

(5)  A  NATO- wide  Data  Element  Attribute  List  should  be  developed.  The  list 
provided  in  Appendix  E  should  be  used  as  a  starting  point. 

(6)  The  recommended  actions  should  commence  as  soon  as  possible  for  the 
specification  of  data  elements  to  be  used  for  developing  and  validating  IERs. 
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(U)  Each  of  the  three  data  concepts  (data  element,  data  value,  and  data  field)  can  be 
categorized  in  two  ways.  The  first  is  to  distinguish  qualitative  data  from  quantitative  data; 
this  is  known  in  ISO  as  data  classification.  The  second  categorization  is  by  data  type,  in 
which  there  are  traditionally  six  types:  character  string,  bit  string,  float  (or  floating  point), 
fixed-point,  integer,  and  boolean  (logical). 

(U)  The  purpose  of  these  two  categories  is  to  provide  a  common  framework  for 
discussing  data  concepts  and  to  ensure  data  are  consistently  treated  and  processed  in 
software. 

I.  CLASSIFICATION  OF  DATA 

(U)  Each  data  concept  may  be  classified  as  quantitative  or  qualitative  (descriptive). 
Quantitative  data  concepts  have  sets  of  assigned  values  that  answer  the  question  "How 
much?" 

(U)  Data  values  can  be  divided  into  two  types  (see  Figure  1):  qualitative  data 
(sometimes  referred  ;o  as  data  items)  and  quantitative  data.  A  data  value,  either  qualitative 
data  or  quantitative  data,  represents  the  content  of  a  data  element--a  piece  of  data  that  has 
been  defined  within  the  context  of  an  organization. 

(U)  Qualitative  data  are  a  non-quantitative  combination  of  characters  or  binaiy 
string  that  represent  a  qualitative  aspect  of  a  person,  place,  thing,  activity,  or  concept.  For 
example,  a  person's  last  name  can  be  a  data  item.  Operations  such  as  compare, 
concatenate,  and  logical  AND/OR  can  be  performed  on  qualitative  data,  where  appropriate. 
Qualitative  data  are  of  three  types:  literal  data,  data  code,  and  image  data. 

•  Literal  Data.  Literal  data  is  a  narrative  or  human-readable  representation  of  a 
data  element.  The  occurrence  of  the  data  element--a  data  value-requires  no 
translation  before  use.  An  example  would  be  the  words  of  text  as  they  appear 
in  this  paragraph. 

•  Data  Code.  A  data  code  is  a  number,  letter,  character,  symbol,  or  combination 
of  them  that  is  used  to  represent  literal  data.  An  example  is  the  two-character 
alphabetic  combination  that  NATO  uses  to  identify  the  NATO  nations:  FR— 
France,  GE-Germany,  UK -United  Ki-  ;  dom,  etc. 
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•  Image  Data.  Image  data  is  normally  a  bit-string  representing  the  results  of 
video,  graphic,  or  photographic  processing,  transfer,  or  storage. 

(U)  Quantitative  data  are  numerical  expressions  such  as:  4,  -3.1,  and 
5.3*10**-3.  Arithmetic  operations  are  performed  on  quantitative  data. 

II.  DATA  TYPES 

(U)  Six  data  types  are  identified  below.  The  first  three  definitions  are  primitive 
types  recognized  by  ASN.l;  all  but  the  integer  type  are  recognized  by  the  Information 
Resource  Dictionary  System  (ERDS)  [Ref.  37]. 

•  Integer.  The  positive  and  negative  whole  numbers,  including  zero;  the  range  is 
unbounded. 

•  Boolean.  A  true  or  false  value. 

•  Bit-string.  An  ordered  set  of  zero  or  more  bits  (i.e.,  0  or  1)  of  unbounded 
length;  the  range  is  effectively  unbounded. 

•  Character-string.  An  ordered  set  of  zero  or  more  characters. 1 

•  Float.  A  number  representation  system  in  which  each  number,  as  represented 
by  a  pair  of  numerals,  equals  one  of  those  numerals  times  a  power  of  an 
implicit  fixed  positive  integer  base  where  the  power  is  equal  to  the  implicit  base 
raised  to  the  exponent  represented  by  the  other  number  (e.g.,  in  BASE  10, 545 
is  5.45*10**2  in  common  notation  or  545+02  in  standard  floating  point 
representation).2 

•  Fixed-point.  A  radix  (point)  numeration  representation  in  which  the  radix 
point  is  implicitly  fixed  in  the  series  of  digit  places  by  some  convention  upon 
which  agreement  has  been  reached  (i.e.,  the  appearance  of  the  radix  or 
"decimal"  point  can  be  implicit  or  explicitly  shown).  For  example,  a  five- 
significant-place  decimal  representation  of  pi  is  3.1416  or  31416,  where  the 
decimal  place  of  the  latter  is  fixed  by  agreement 

III.  DOMAINS 

(U)  The  concepts  of  generic  element  and  data  element,  discussed  in  Section  3.3  of 
the  main  body  of  this  Working  Paper,  are  both  constrained  by  needing  an  agreed  set  of 


1  (U)  The  ISO  definition  of  "character":  a  member  of  a  set  of  elements  upon  which  agreement  has  been 
reached  and  that  is  used  for  the  organization,  control,  or  representation  of  data  [Ref.  1 1). 

2  (U)  Vocabulary  for  Information  Processing,  X3. 12-1970,  ANSI,  December  1970. 
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acceptable  values.  This  limitation  is  called  a  domain  or,  more  precisely,  a  domain  set.3 
When  the  domain  set  of  a  data  element  is  specified,  the  domain  set  can  be  divided  into  two 
types:  specific  and  general.  These  types  are  discussed  below. 

A.  Specific  Domain 

(U)  A  specific  domain  has  a  definition  together  with  a  discrete,  finite  set  of 
acceptable  values.  For  a  specific  domain,  one  can  always  explicitly  compile  a  complete  list 
of  these  acceptable  values.  As  an  example,  the  specific  domain  set  for  the  data  element 
"NATO  country  code-of-world"  is  {BE,  CA,  DA,  FR,  GE,  GR,  IC,  IT,  LU,  NL,  NO, 
PO,  SP,  TU,  UK,  US}.  Codes  or  identifiers  are  usually  specified  by  such  a  domain. 
Once  an  agreed  to  domain  has  been  established,  at  the  generic  element  level,  data  elements 
standardized  on  that  domain  must  use  the  whole  domain  set  or  a  subset  of  that  domain.  As 
in  this  example,  the  16  codes  in  the  data  element  are  a  subset  of  the  domain  set  specified  in 
the  generic  element  "country  code-of-world." 

B .  General  Domain 

(U)  A  general  domain  (set)  specifies  its  limitations  in  terms  of  a  general  definition 
or  a  range  of  acceptable  values.  In  DP  7826  [Ref.  1 1]  the  following  example  is  given  by 
ISO  for  the  domain  of  the  generic  element  "code": 

Coded  representations  shall  consist  of  up  to  35  characters  that  uniquely 
represent  a  complete  name  of  a  data  (value),  selected  from  a  data  (value)  set 
of  a  data  element,  within  a  coding  scheme.  Unless  otherwise  specified,  the 
coded  representation  shall  use  the  following  subset  of  ISO  646  International 
Reference  Version  (IRV):  (a)  the  letters  A  to  Z  single  case  only;  (b)  the 
digits  0  to  9;  (c)  space;  (d)  hyphen;  (e)  point;  (f)  solidus,4  [and]  (g)  colon. 

This  is  a  an  example  of  a  general  domain. 


3  (U)  The  use  of  the  term  "domain"  here  differs  from  its  use  in  WP  24. 

4  (U)  Solidus  is  sometimes  called  "backslash"  and  represented  as  "\". 
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(U)  The  following  is  a  list  of  class  words  that  can  be  used  to  support  the  naming  of 
Generic  Elements.  The  class  word  is  used  to  specify  the  type  of  information  contained  in  a 
domain.  Through  the  naming  conventions,  the  domain  specified  by  the  class  word  (plus  a 
modifier  and  qualifiers)  is  associated  with  a  data  element.  Listed  below  are  the  class  words 
segregated  by  category: 

A.  QUALITATIVE 

1 .  IDENTIFICATION  CLASS  WORDS 

(a)  NAME— A  designation  for  an  object  expressed  in  a  word  or  words. 

(b)  ABBREVIATION— A  shortened  form  of  a  word,  phrase,  or  name 
used  to  represent  the  complete  form.  Mnemonics  are  considered 
abbreviations. 

(c)  CODE— A  group  of  alphabetic  letters  and/or  digits  that  represent  a 
specific  name.  Acronyms  are  considered  codes. 

(d)  IDENTIFIER— A  sequence  of  alphabetic  characters  that  serve  to 
indicate  some  object 

(e)  NUMBER-A  nonquantitative  number  associated  with  an  object. 

2 .  DESCRIPTIVE  CLASS  WORDS 

(a)  CATEGORY- A  specifically  defined  division  or  subset  in  a  system 
of  classification  in  which  all  items  share  the  same  concept  of  taxonomy. 

(b)  TEXT-An  unformatted  character  string  descriptive  field. 

B .  QUANTITATIVE 

1 .  TIME-RELATED  CLASS  WORDS 

(a)  AGE-The  length  of  time  a  person  or  thing  has  lived  or  existed. 

(b)  DATE-A  calendar  date,  commonly  expressed  by  month,  day,  and 
year. 

(c)  DATE-TIME-GROUP— Time  (day,  hour,  and  minute)  and  date 
(month  and  year)  in  the  format  DDHHMMZMMMYY. 

(d)  TIME-A  specific  point  in  the  day  expressed  within  the  2400  hours 
clock. 
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(e)  YEAR--The  period  of  time  as  measured  by  the  Gregorian  calendar, 
consisting  of  approximately  365  days  beginning  on  January  1  and  ending 
on  December  31. 

POSITION-RELATED  CLASS  WORDS 

(a)  LOCATION-A  position  or  site  on  the  earth's  surface  represented  by 
Mercator  Projection  grid  coordinates. 

(b)  LATITUDE-Angular  distance  north  or  south  from  the  earth's 
equator  measured  through  90  degrees.  The  format  is  degrees,  minutes, 
seconds,  hemisphere. 

(c)  LONGITUDE— The  arc  or  portion  of  the  earth's  equator  intersected 
between  the  meridian  of  a  given  place  and  the  prime  meridian  (Greenwich, 
England)  expressed  in  degrees.  The  format  is  degrees,  minutes,  seconds, 
hemisphere. 

MEASUREMENT  CLASS  WORDS 

(a)  ACCELERATION-The  rate  of  change  of  velocity. 

(b)  ANGLE— The  measurement  of  the  space  formed  by  two  lines 
diverging  from  a  common  point 

(c)  AREA— The  number  of  unit  squares  equal  in  measure  to  the  surface. 

(d)  DENSITY-The  amount  of  particular  items  of  interest  per  unit  of 
measure. 

(e)  DEPTH-The  linear  measurement  downward,  backward,  or  inward. 

(f)  DISTANCE-The  extent  of  advance  away  or  along  from  a  point 
considered  primary  or  original. 

(g)  FLOW— The  continuous  movement,  circulation,  or  throughput  of  a 
substance. 

(h)  FORCE-The  intensity  of  strength,  vigor,  or  power. 

(i)  HEIGHT-The  distance  from  the  base  to  the  top  of  something 
standing  upright. 

(j)  HUMIDITY— The  amount  of  water  vapor  in  the  air. 

(.v)  LENGTH-The  longer  or  longest  dimension  of  an  object. 

(l)  MASS-The  physical  volume  or  bulk  of  a  body. 

(m)  PRESSURE-A  measure  of  applied  force  per  unit  area. 

(n)  RANGE-The  extent  covered  by  something. 

(o)  TENSION— A  measure  for  tautness  caused  by  pulling  or  stretching 
something. 

(p)  TEMPERATURE-A  measure  of  the  degree  of  hotness  or  coldness 
of  something. 

(r)  TORQUE-A  measure  for  a  turning  or  twisting  force. 

(s)  VELOCITY -The  rate  of  motion. 
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(t)  VISCOSITY-The  degree  to  which  a  substance  resists  flowing. 

(u)  VOLUME-The  amount  of  space  occupied  by  a  three-dimensional 
figure  as  measured  in  cubic  units. 

(v)  WEIGHT--The  force  with  which  a  body  or  object  is  attracted  toward 
the  earth  by  gravitation. 

(w)  WIDTH-The  measurement  taken  at  right  angles  to  the  length. 

(x)  SIZE-The  physical  dimensions  or  magnitude  of  something. 

4 .  COMPUTATIONAL  CLASS  WORDS 

(a)  AMOUNT-The  monetary  value  arrived  at  by  counting. 

(b)  COST-The  amount  paid  or  required  in  payment  for  a  purchase. 

(c)  QUANTITY -Non- monetary  numeric  value  arrived  at  by  counting. 

C .  MEASUREMENT  AND  COMPUTATIONAL  CLASS  WORD 
QUALIFIERS 

1 .  AVERAGE-The  arithmetic  mean  of  numbers. 

2 .  MEDIAN— The  middle  value  in  a  distribution,  above  and  below  which  lie  an 
equal  number  of  values. 

3 .  PERCENT-One  part  of  a  hundred. 

4.  RATIO-The  calculated  relation  in  degree  or  number  between  two  similar 
things. 

5 .  TOTAL-The  final  sum  of  amounts,  costs,  or  quantity. 

(U)  The  above  list  is  by  no  means  exhaustive  in  nature,  but  rather  represents  a 
starting  point  based  on  some  ongoing  efforts.  It  is  envisioned  that  this  list  will  grow  as  the 
need  for  additional  class  words  are  identified.  However,  the  class  word  list  that  is  adopted 
must  be  controlled  and  kept  to  a  minimum. 
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APPENDIX  C 

ARCHITECTURAL  MODIFIERS  AND  PRIME  WORD  LIST 

(U)  The  following  is  a  list  of  the  architectural  modifiers  and  prime  words  that  can 
be  used  to  support  the  naming  of  generic  elements  and  data  elements.  The  prime  word 
represents  the  objects  to  which  an  application  data  element  belongs.  The  architectural 
modifier  is  at  a  macro-organizational  level,  or  in  other  words,  the  first  major  division  of 
information  within  a  specific  organization.  The  architectural  modifier  provides  the  logical 
connection  between  the  data  element  and  an  organization's  data  architecture  or  data  model. 
The  architectural  modifier  should  be  the  first  word  in  the  data  element  name  and  may  also 
serve  as  the  prime  word  for  the  data  element  name  if  so  desired.  Architectural  modifiers 
should  appear  on  the  prime  word  list;  however,  not  all  prime  words  are  architectural 
modifiers. 

(U)  An  initial  set  of  architectural  modifiers  and  prime  words  has  been  listed  below. 
As  time  progresses  and  experience  is  gained,  this  list  would  change  accordingly.  Other 
prime  words  would  be  recommended  for  inclusion  to  the  prime  word  list. 

(U)  The  architectural  modifiers  have  been  mapped  below  to  their  information  class 
and  Army  Data  Architecture  Subject  Area.  The  architectural  modifier  within  each  subject 
area  may  be  associated  with  any  information  class  within  that  subject  area.  However,  an 
architectural  modifier  may  not  be  associated  with  an  information  class  outside  of  the  subject 
areas  assigned  below.  "Associated"  means  appearing  as  the  first  word  in  a  data  element 
name  that  supports  a  specific  information  class. 

(U)  The  architectural  modifiers  listed  below,  in  accordance  with  the  naming 
conventions  specified  in  Chapter  6,  are  used  as  modifiers  of  prime  words. 

A.  ARCHITECTURAL  MODIFIER  MAPPING 

1.  DATA  MODEL  SUBJECT  AREA:  Acquisition 

INFORMATION  CLASSES: 

Personnel  Accessions 
Materiel  Acquisition 
Facilities  Acquisition 
Industrial  Capability 
Materiel  Improvement 
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ARCHITECTURAL  MODIFIERS: 

Acquisition 

Industrial 

2.  DATA  MODEL  SUBJECT  AREA:  Budget 

INFORMATION  CLASSES: 

Cash/Funds  Authorizations 
Program/Budget  Execution 
Accounting 
Budget 

ARCHITECTURAL  MODIFIERS: 

Accounting 

Budget 

Finance 

Resource 

3 .  DATA  MODEL  SUBJECT  AREA:  Commercial  Activities 

INFORMATION  CLASSES: 

Commercial  Activities 
ARCHITECTURAL  MODIFIERS: 

Commercial 

Contractor 

Supplier 

Vendor 

4.  DATA  MODEL  SUBJECT  AREA:  Contracts 

INFORMATION  CLASSES: 

Contracts 

ARCHITECTURAL  MODIFIERS: 

Contract 

Agreement 

5 .  DATA  MODEL  SUBJECT  AREA:  Crisis  Operations 

INFORMATION  CLASSES: 

Crisis  Operation 

ARCHITECTURAL  MODIFIERS: 

Catastrophic 

Crisis 

Disaster 
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Relief 

Special 

Unconventional 

6.  DATA  MODEL  SUBJECT  AREA:  Facilities 
INFORMATION  CLASSES: 

Installation 
Facilities  Maintenance 
Facilities  Disposal 
ARCHITECTURAL  MODIFIERS: 


Annex 

Maintenance 

Base 

Office 

Camp 

Post 

Cemetery 

Production 

Construction 

Range 

Engineering 

Reservation 

Facility 

Storage 

Housing 

Terminal 

7.  DATA  MODEL  SUBJECT  AREA:  Funds 

INFORMATION  CLASSES: 

Funds 

Disbursement 

ARCHITECTURAL  MODIFIERS: 

Appropriated 

Compensation 

Disbursement 

Funds 

Receipt 

8 .  DATA  MODEL  SUBJECT  AREA:  Government  Liaison 

INFORMATION  CLASSES: 

External  Guidance 
Foreign  Liaison 
Government  Liaison 
ARCHITECTURAL  MODIFIERS: 

Executive  International 

External  Interservice 

Foreign  Liaison 
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Government  National 

Interheadquarters 


9.  DATA  MODEL  SUBJECT  AREA:  Guidance  &  Doctrine 
INFORMATION  CLASSES: 


Strategic  Direction 
Doctrine 


ARCHITECTURAL  MODIFIERS: 


Command 

Direction 

Directive 

Policy 


Priority 

Regulation 

Strategic 

Strategy 


10.  DATA  MODEL  SUBJECT  AREA:  Information  Management 
INFORMATION  CLASSES: 


Information  Management 
ARCHITECTURAL  MODIFIERS: 


Audio 

Automation 

Communication 

Computer 

Information 

Library 


Printing 

Publication 

Record 

Telecommunications 

Visual 


11.  DATA  MODEL  SUBJECT  AREA:  Intelligence 
INFORMATION  CLASSES: 


Intelligence 

ARCHITECTURAL  MODIFIERS: 


Counterintelligence 

Deception 

Enemy 

Geographic 

Intelligence 


Mapping 
Nuclear  Surety 
Reconnaissance 
Topology 
Weather 


12.  DATA  MODEL  SUBJECT  AREA:  Materiel 
INFORMATION  CLASSES: 

Materiel  Distribution 
Materiel  Inventory 
Materiel  Maintenance 
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Materiel  Disposition 
ARCHITECTURAL  MODIFIERS: 


Developer 

Equipment 

Inventory 

Logistic 


Major-Item 

Materiel 

Supply 


13.  DATA  MODEL  SUBJECT  AREA:  Operational  Testing  (OT) 
INFORMATION  CLASSES: 

Testing  (OT) 

ARCHITECTURAL  MODIFIERS: 

Evaluation 

Test 


14.  DATA  MODEL  SUBJECT  AREA:  Operations  Plans 
INFORMATION  CLASSE: 


Plans  (Operation) 

Deployment 

ARCHITECTURAL  MODIFIERS: 


Air-Defence 

Air-Ground 

Assessment 

Biological 

Battlefield 

Barrier 

Capability 


Chemical 

Defence 

Deployment 

Exercise 

Fire- Support 

Intertheatre 

Intratheatre 


Long-range 

Manoeuver 

Mobilization 

Movement 

Nuclear 

Obstacles 

Offense 


Operation 

Operational 

Plan 

Psychological 

Transport 

Warfare 


15.  DATA  MODEL  SUBJECT  AREA:  Personnel 
INFORMATION  CLASSES: 

Personnel  Distribution 
Personnel  Strength 
Casualties 

Personnel  Sustainment 
Personnel  Transitions 
ARCHTTECTURAL  MODIFIERS: 
Civilian 
Dependent 
Equal-Opportunity 


Member 

Military 

Personnel 
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Family  Union 

Local 

16.  DATA  MODEL  SUBJECT  AREA:  Public  Affairs 
INFORMATION  CLASSES: 

Public  Affairs 

ARCHITECTURAL  MODIFIERS: 

Affair 

Public 


17.  DATA  MODEL  SUBJECT  AREA:  Readiness 
INFORMATION  CLASSES: 


Force  Readiness 


ARCHITECTURAL  MODIFIERS: 


Force 

Readiness 


18.  DATA  MODEL  SUBJECT  AREA:  Research  and  Development 
INFORMATION  CLASSES: 

RDTE 

ARCHITECTURAL  MODIFIERS: 


Electronic 

Experiment 

Development 

Laboratory 

Life-Science 

Protocol 

19.  DATA  MODEL  SUBJECT  AREA:  Security 
INFORMATION  CLASSES: 

Security 

Law  Enforcement 
ARCHITECTURAL  MODIFIERS: 

Discipline 

Law-and-Order 

Prisoner 


Research 

Sample 

Science 

Subject 

Technology 


Physical 

Security 

Surveillance 
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20.  DATA  MODEL  SUBJECT  AREA:  Security  Assistance 

INFORMATION  CLASSES: 

Security  Assistance 
ARCHITECTURAL  MODIFIERS: 

Security 

Assistance 

2 1 .  DATA  MODEL  SUBJECT  AREA:  Structure 

INFORMATION  CLASSES: 

Structure 

Manpower  Requirements 
Manpower  Authorizations 
Materiel  Requirements 
Materiel  Authorizations 
Facilities  Requirements 
Facilities  Authorizations 
ARCHTTECTURAL  MODIFIERS: 

Authorization 

Manpower 

Structure 

22.  DATA  MODEL  SUBJECT  AREA:  Studies  Program 

INFORMATION  CLASSES: 

Study  Program 

ARCHITECTURAL  MODIFIERS: 

Study 

23.  DATA  MODEL  SUBJECT  AREA:  Support  Activities 

INFORMATION  CLASSES: 

Inspection  Results 
Audit  Findings 
Legal  Support 
Community  Support 
Health  Support 
Safety 

Individual  Entitlement 


♦ 
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Claims 

ARCHTTECTURAL  MODIFIERS: 

Administration 
Audit 
Clinic 
Community 
Health 
Hospital 
Inspection 

24.  DATA  MODEL  SUBJECT  AREA:  Training 

INFORMATION  CLASSES: 

Institutional  Training 
Individual  and  Unit  Proficiency 
ARCHITECTURAL  MODIFIERS: 

Institutional 
Training 

25 .  DATA  MODEL  SUBJECT  AREA:  Transportation  (non- Army) 

INFORMATION  CLASSES: 

Transportation  (non- Army) 

ARCHITECTURAL  MODIFIERS: 

Air 

Land 

Rail 

Sea 

Transportation 

26.  DATA  MODEL  SUBJECT  AREA:  Unit(s)  and  Organization(s) 

INFORMATION  CLASSES: 

Review  and  Analysis  Results 
Internal  Management 
ARCHITECTURAL  MODIFIERS: 


Army 

Report 

Documentation 

Reserve 

Goal 

Standard 

Management 

Tactical 

Organization 

Unit 

Procedure 

Installation 

Investigation 

Legal 

Religious 

Safety 

Soldier 

Support 
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Accounting 

Berth 

Acquisition 

Biological 

Administration 

Budget 

Affair 

Bunker 

Agency 

Camp 

Agreement 

Capability 

Air 

Cargo 

Air-Defence 

Carrier 

Air-Ground 

Catastrophic 

Aircraft 

Cemetery 

Airfield 

Channel 

Airlift 

Chart 

Airport 

Chemical 

Ammunition 

Civilian 

Anchorage 

Clinic 

Annex 

Combat 

Appropriated 

Command 

Apron 

Commercial 

Arctic 

Communication 

Army 

Community 

Arresting-Gear 

Compensation 

Arrival 

Complex 

Assessment 

Component 

Asset 

Computer 

Assistance 

Construction 

Audio 

Container 

Authorization 

Contract 

Automation 

Contractor 

Barrier 

Conversion 

Base 

Counterintelligence 

Battlefield 

Country 

Crane 

Fire-Support 

Crisis 

Force 

Deception 

Foreign 

Defence 

Fuel 

Departure 

Funds 

Dependent 

Geographic 

Deployment 

Goal 

Description 

Government 

Developer 

Harbour 

Development 

Health 

Direction 

Hospital 

Directive 

Hostilities 

Disaster 

Housing 

Disbursement 

Ice 

Discipline 

Industrial 

Diseased 

Information 

Document 

Inspection 

Electricity 

Installation 

Electronic 

Institutional 

Encyclopedia 

Intelligence 

Enemy 

Interheadquarter 

Engineering 

International 

Equipment 

Interservice 

Evacuee 

Intertheatre 

Evaluation 

In  tra  theatre 

Executive 

Inventory 

Exercise 

Investigation 

Experiment 

Item 

External 

Laboratory 

Facility 

Land 

Family 

Language 
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Bed 

Craft 

Legal 

Operation 

Liaison 

Operational 

Library 

Organization 

Life-Science 

Outpatient 

Lighter 

Patient 

Local 

Personnel 

Location 

Petroleum 

Logistic 

Physical 

Long-range 

Pipeline 

Maintenance 

Plan 

Major-Item 

Policy 

Management 

Port 

Manoeuvre 

Post 

Manpower 

Printing 

Mapping 

Priority 

Materiel 

Prisoner 

Medical 

Procedure 

Member 

Production 

Message 

Program 

Military 

Project 

Mission 

Protocol 

Mobilization 

Psychological 

Movement 

Public 

Nation 

Publication 

National 

Rail 

Non- Evacuee 

Railroad 

Nuclear 

Ramp 

Nuclear  Surety 

Range 

Obstacles 

Readiness 

Offense 

Receipt 

Office 

F  econnaissance 

Finance 

Law-and-Order 

Record 

Subject 

Regulation 

Supplier 

Relief 

Supply 

Religious 

Support 

Report 

Surveillance 

Requirement 

Tactical 

Research 

Technology 

Reservation 

Telecommunications 

Reserve 

Terminal 

Resource 

Test 

Road 

Theatre 

Runway 

Tidal 

Safety 

Topology 

Sample 

Training 

Science 

Transport 

Sea 

Transportation 

Seaport 

Tugboat 

Security 

Unconventional 

Sequence 

Union 

Service 

Unit 

Ship 

Vendor 

Soldier 

Visual 

Special 

War 

Standard 

Warfare 

State 

Water 

Stock 

Weather 

Storage 

Wharf 

Strategic 

Work 

Strategy 

Zone 

Structure 

Study 
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APPENDIX  D 

"OF-LANGUAGE"  NAMING  CONVENTION 


(U)  In  its  discussion  of  data  terminology,1  AM  96-1-4  discusses  only  one  naming 
convention,  the  so-called  "OF-Language"  (based  on  a  proprietary  concept  developed  by 
IBM),  and  recommends  it  for  adaption,  as  appropriate,  in  ACE. 

(U)  The  general  format  for  a  name  in  the  "OF-Language"  convention  is: 

P  .  QQQ  [R  SSS][R  SSS]  [R  SSS] 

where: 

P  indicates  type  of  name  (from  a  list  of  valid  types  given  below) 
means  "OF' 

QQQ  is  a  global  noun  (e.g.,  listed  in  a  data  dictionary) 

R  is  a  connector  for  descriptions  (from  a  list  of  valid  connectors  given  below) 
SSS  is  a  descriptor  (adjective). 

Connector/descriptor  pairs,  denoted  [R  SSS],  are  used  optionally  and  may  be  repeated  as 
appropriate. 

(U)  Valid  type-of-name  ["P"]  values  are:  Amount  (A),  Code  (C),  Date  (D),  Flag 
(F),  Constant  (K),  Name  (N),  Number  (O),  Percent  (P),  Quantity  (Q),  Text  (T),  and 
Control  (X).  Valid  values  of  the  connector  ["R"]  are: 

/  meaning  "which  is" 

meaning  "Compound"  [the  symbol  is  hyphen] 

$  meaning  "OR” 

#  meaning  "AND" 

@  meaning  "by,"  "per",  "for",  or  "with" 

meaning  "initiator"  [the  symbol  is  underscore]. 

(U)  The  following  are  valid  examples  of  names  in  the  "OF-Language,"  taken  from 
AM  96-1-4: 

A.SALARY/BASE#COMMISSION  Amount  of  salary  that  is  Base  and 

Commission 


1  (U)  "Data  Terminology,"  Annex  A,  AM  96-1-4  [Ref.  6],  Section  l.L. 
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Q.AIRCRAFT/STANDBY  Quantity  of  Aircraft  that  arc  on  standby 

N.COUNTRY/NATO  Name  of  Country  that  is  in  NATO 

C.COUNTRY/NATO  Code  of  Country  that  is  in  NATO 

P.MENES/REMAINING/ACOUSTIC  Percentage  of  mines  remaining  that  are 

acoustic. 
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ATTRIBUTE  LIST 


1 .  GENERIC  ELEMENT 

1.1  Administrative  Attributes 

(U)  Administrative  attributes  for  generic  elements  are: 

•  INFORMATION  GENERIC  ELEMENT  NAME  -  A  character  string  given  to  a 
generic  element  based  on  a  class  word  that  identifies  a  domain. 

•  INFORMATION  ELEMENT  APPROVAL  DATE  -  The  date  a  standard 
element  is  approved  as  an  ATCCIS  standard. 

•  INFORMATION  ELEMENT  CLASS  WORD  NAME  -  A  character  string 
(word)  from  a  reserved  list  that  identifies  the  generic  element. 

•  INFORMATION  ELEMENT  MODIFIER  NAME  -  A  character  string  that 
further  describes  a  characteristic  of  an  object,  a  relationship  between  objects,  or 
the  object  itself. 

•  INFORMATION  GENERIC  ELEMENT  QUALIFIER  NAME  -  A  character 
string  that  modifies  a  class  word.  It  is  normally  associated  with  quantities. 

•  INFORMATION  GENERIC  ELEMENT  DEFINITION  TEXT  -  narrative 
describing  the  general  intent  of  a  generic  element 

1 . 2  Relational  Attributes 

(U)  Relational  attributes  for  generic  elements  are: 

•  INFORMATION  ELEMENT  STANDARDIZATION  AUTHORITY 
ATTRIBUTE  IDENTIFIER  -  The  NATO,  SHAPE,  or  Command  organization 
that  approved  the  element 

•  INFORMATION  ELEMENT  AUTHORIZATION  DOCUMENT  NAME  -  A 
character  string  given  to  the  document  (directive,  regulation,  publication,  or 
other)  that  authorizes  the  generic  element 
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1.3  Representational  Attributes 

(U)  Representational  attributes  for  generic  elements  are: 

•  INFORMATION  ELEMENT  DATA  TYPE  CATEGORY  -  The  editing  type  of 
the  data  value  associated  with  an  element 

•  INFORMATION  ELEMENT  MAXIMUM  DATA  VALUE  LENGTH  -  The 
maximum  number  of  characters  for  an  attribute. 

•  INFORMATION  GENERIC  ELEMENT  DOMAIN  DEFINITION  TEXT  - 
Narrative  describing  the  acceptable  set  of  data  values  for  a  generic  element 

•  INFORMATION  DATA  VALUE  TYPE  IDENTIFIER  -  An  indicator 
specifying  the  data  value  type  of  an  information  element 

•  INFORMATION  ELEMENT  JUSTIFICATION  CATEGORY  -  The  positional 
justification  of  an  element  within  a  data  field. 

'•  INFORMATION  DATA  VALUE  SOURCE  LIST  TEXT  -  The  source  in 
which  lengthy  codes  are  enumerated  for  the  user.  The  source  can  be  either 
manual  or  automated  medium. 

1.3.1  Relating  to  Qualitative  Data 

(U)  Representational  attributes  relating  to  qualitative  data  for  generic 

elements  are: 

•  INFORMATION  DATA  VALUE  NAME  -  An  occurrence  of  a  character  string 
given  to  an  acceptable  set  of  data  values. 

•  INFORMATION  DATA  VALUE  DEFINITION  TEXT  -  Narrative  describing 
a  data  value  name  or  number  specified  in  a  domain  set 

1.3.2  Related  to  Quantitative  Data 

(U)  Representational  attributes  relating  to  quantitative  data  for  generic 

elements  are: 

•  INFORMATION  QUANTITATIVE  DATA  HIGH  RANGE  NUMBER  -  The 
largest  value  for  quantitative  data,  when  a  domain  set  is  expressed  as  a  possible 
range  of  values. 

•  INFORMATION  QUANTITATIVE  DATA  LOW  RANGE  NUMBER  -  The 
smallest  value  for  quantitative  data,  when  a  domain  set  is  expressed  as  a 
possible  range  of  values. 

•  INFORMATION  QUANTITATIVE  DATA  SCALE  NUMBER  -  The  integer 
that  determines  the  decimal  point  placement  in  an  element  for  fixed  point  or 
floating  point  data  types. 
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•  INFORMATION  QUANTITATIVE  DATA  VALUE  NUMBER  -  The  set  of 
values  for  quantitative  data,  when  mathematical  operations  must  be  performed 
on  "codes." 

•  INFORMATION  QUANTITATIVE  DATA  VALUE  DEFINITION  TEXT  - 
Narrative  describing  a  data  value  name  or  number  specified  in  a  domain  set 

2 .  DATA  ELEMENT 

2.1  Administrative  Attributes 

(U)  Administrative  attributes  for  data  elements  are: 

•  INFORMATION  DATA  ELEMENT  NAME  -  A  character  string  given  to  a  data 
element  based  on  a  prime  term  and  a  generic  element  name. 

•  INFORMATION  PRIME  WORD  NAME  -  A  character  string  in  a  data  element 
name  that  represents  the  data  grouping  to  which  the  data  element  belongs. 

•  INFORMATION  DATA  ELEMENT  ARCHITECTURAL  MODIFIER  NAME 
-  A  data  element  character  string  directly  related  to  a  subject  area  in  the 
ATCCIS  data  architecture. 

•  INFORMATION  DATA  ELEMENT  DESCRIPTION  TEXT  -  Narrative 
describing  a  data  element 

•  INFORMATION  DATA  ELEMENT  MNEMONIC  ABBREVIATION  -  A 
short  form  of  a  data  element  character  string. 

•  INFORMATION  DATA  ELEMENT  SECURITY  CATEGORY  -  The  level  of 
security  that  the  value  set  of  this  data  element  requires. 

•  INFORMATION  DATA  ELEMENT  STATUS  IDENTIFIER  -  An  indicator  of 
the  current  status  of  a  data  element  in  relation  to  the  standardization  process. 

•  INFORMATION  DATA  ELEMENT  COMMENT  TEXT  -  Administrative 
comment  concerning  a  data  element 

2.1.1  Defined  at  the  Generic  Element  Level 

•  INFORMATION  ELEMENT  APPROVAL  DATE 

•  INFORMATION  DATA  ELEMENT  QUALIFIER  NAME 

•  INFORMATION  ELEMENT  MODIFIER  NAME 
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2 . 2  Relational  Attributes 

(U)  Relational  attributes  for  data  elements  are: 

•  INFORMATION  DATA  ARCHITECTURE  SUBJECT  AREA  NAME  -  A 
character  string  given  to  a  data  architecture  entity  subject  area. 

•  INFORMATION  CLASS  NAME  -  A  character  string  given  to  the  class  of 
information  to  which  a  data  element  is  assigned  in  accordance  with  the 
Information  Model. 

•  INFORMATION  PROCESS  NAME  -  A  character  string  given  to  a  process 
that  creates  an  information  class  in  accordance  with  the  current  Information 
Model. 

•  INFORMATION  CLASS  PROPONENT  NAME  -  A  character  string  given  to 
an  organization  that  has  been  assigned  responsibility  for  an  information  class. 

•  INFORMATION  DATA  ELEMENT  RESPONSIBLE  OFFICE  NAME  -  A 
character  string  given  to  the  office  and/or  person  desig.  ated  by  the  information 
class  proponent  as  the  functional  expert  for  defining,  reviewing,  and  updating 
a  data  element  and  its  attributes. 

2 . 3  Representational  Attributes 

(U)  Representational  attributes  for  data  elements  are: 

•  INFORMATION  DATA  ELEMENT  DOMAIN  DEFINITION  TEXT  - 
Narrative  describing  the  data  values  acceptable  for  a  data  element.  The 
specification  for  the  element  must  be  the  set  or  subset  of  a  generic  element 
definition.  It  may  not  contain  data  values  outside  the  set.  This  definition 
includes  the  range  of  acceptable  values. 

•  INFORMATION  DATA  ELEMENT  TIMELINESS  IDENTIFIER  -  An 
indicator  of  how  often  data  values  must  be  updated. 

•  INFORMATION  DATA  ELEMENT  LENGTH  -  The  maximum  number  of 
characters  in  a  standard  data  element. 

2.3.1  Defined  at  the  Generic  Element  Level 

•  INFORMATION  DATA  VALUE  TYPE  IDENTIFIER 

•  INFORMATION  ELEMENT  JUSTIFICATION  CATEGORY 

•  INFORMATION  ELEMENT  CODE  LOCATION 
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2.3.2  Related  to  Qualitative  Data 

(U)  Representational  attributes  relating  to  qualitative  data  for  data 

elements  are: 

•  INFORMATION  QUALITATIVE  DATA  VALUE  ACCURACY  NUMBER 
PERCENT  -  An  indicator  of  how  accurate  a  qualitative  data  value  must  be. 

2.3.3  Related  to  Qualitative  Data  Defined  at  the  Generic 
Element  Level 

•  INFORMATION  DATA  VALUE  NAME 

•  INFORMATION  DATA  VALUE  DEFINITION  TEXT 

2.3.4  Related  to  Quantitative  Data 

(U)  Representational  attributes  relating  to  quantitative  data  for  data 

elements  are: 

•  INFORMATION  QUANTITATIVE  DATA  ACCURACY  IDENTIFIER  -  An 
indicator  of  how  precise  a  quantitative  data  value  must  be. 

•  INFORMATION  DATA  ELEMENT  CALCULATION  FORMULA  TEXT  - 
Narrative  expressing  the  algorithmic  formula  for  a  data  element  that  is  derived. 

2.3.5  Related  to  Quantitative  Data  Defined  at  the  Generic 
Element  Level 

•  INFORMATION  QUANTITATIVE  DATA  HIGH  RANGE  NUMBER 

•  INFORMATION  QUANTITATIVE  DATA  LOW  RANGE  NUMBER 

•  INFORMATION  QUANTITATIVE  DATA  SCALE  IDENTIFIER 

•  INFORMATION  DATA  VALUE  DEFINITION  TEXT 

•  INFORMATION  QUANTITATIVE  DATA  VALUE  NUMBER 

3 .  DATA  ELEMENT  ALIAS 

3.1  Administrative  Attributes 

(U)  Administrative  attributes  for  data  element  aliases  are: 

•  INFORMATION  DATA  ELEMENT  ALIAS  NAME  -  A  character  string  given 
to  a  nonstandard  data  element 
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•  INFORMATION  DATA  ELEMENT  ALIAS  HOST  APPLICATION  NAME  - 
A  character  string  given  to  an  application  or  program  that  contains  a  data 
element  alias. 

•  INFORMATION  DATA  ELEMENT  ALIAS  HOST  SYSTEM  NAME  -  A 
character  string  given  to  an  information  system  that  contains  a  data  element 
alias. 

3 . 2  Relational  Attributes 

(U)  Relational  attributes  for  data  element  aliases  are: 

•  INFORMATION  DATA  ELEMENT  ALIAS  RESPONSIBLE  OFFICE  NAME 
-  A  character  string  given  to  the  office  and/or  person  designated  by  the 
information  class  proponent  as  the  functional  expert  for  defining,  reviewing, 
and  updating  a  data  element  alias  and  its  attributes. 

3.2.1  Defined  at  the  Data  Element  Level 

•  INFORMATION  DATA  ELEMENT  NAME 

3 . 3  Representational  Attributes 

(U)  The  representational  attributes  at  the  data  element  alias  level  are 
identical  to  the  Data  Element  Level,  except  they  are  used  only  to  report  exceptions  where 
that  alias  deviates  from  the  established  standard. 

4 .  RELATION  OF  ATTRIBUTES  TO  OTHER  STANDARDS 

(U)  The  attributes  listed  in  this  section  were  identified  in  ISO/IEC  DP  10027, 
1  April  1988,  from  the  Element  Entity  level  of  the  IRDS.  Other  attributes  have  been  added 
to  the  attribute  set  associated  with  the  development  of  a  data  model  to  support  the 
standardization  process. 
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APPENDIX  F 

NATIONAL  INITIATIVES  ON  DATA  MANAGEMENT 


(U)  This  Appendix  briefly  describes  some  of  the  national  initiatives  being 
conducted  to  define  a  policy  for  data  management  and  standardization. 

I.  DATA  MANAGEMENT  POLICY  FOR  THE  U.S.  ARMY 

(U)  The  U.S.  Army  has  recently  published  an  Army  Regulation  (AR  25-9)  [Ref. 
35]  to  prescribe  policies,  responsibilities,  and  concept  of  operation  for  the  management  of 
data  used  in  manual  and  automated  information  systems  throughout  the  U.S.  Army.  This 
document  was  coordinated  with  ISO,  ANSI,  and  the  U.S.  National  Bureau  of  Standards, 
as  well  as  with  the  U.S.  Joint  Chiefs  of  Staff,  to  ensure  alignment  in  the  area  of  a  data 
element  naming  convention.  The  Army  plans  to  maintain  a  Service-wide  data  encyclopedia 
of  information  about  all  data  elements  that  have  gone  through  a  standardization  process  and 
are  designated  as  Army  standard  elements.  AR  25-9  addresses  six  activities  that  form  the 
Army  Data  Management  and  Standards  Program: 

•  Strategic  Data  Planning.  The  development  and  maintenance  of  data-related 
initiatives  in  integrated  organizational  multiyear  long-range  plans. 

•  Data  Element  Standards.  The  standardization  and  management  of  data 
elements  and  their  attributes. 

•  Information  Management  Control.  The  interface  between  data  management 
and  control  of  the  collection  and  reporting  of  management  information 
requirements. 

•  Data  Security.  The  policies  and  procedures  required  to  protect  and  safeguard 
data  and  information,  including  operational  security. 

•  Data  Synchronization.  The  policies  and  procedures  that  govern  the 
consistency,  accuracy,  reliability,  and  timeliness  of  data  used  and  generated  by 
the  Army. 

•  Database  Development  and  Maintenance.  The  policies  and  standards  that  guide 
design,  development,  documentation,  and  integration  of  data  bases. 

(U)  AR  25-9  provides  for  three  types  of  standard  elements:  reference  element,  data 
element,  and  data  element  alias.  A  reference  element  is  a  structure  used  to  specify  the 
domain  or  the  range  of  acceptable  values.  A  data  element  consists  of  a  data  element  name, 
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together  with  attributes  describing  what  it  is,  its  representation,  and  relationships  to  other 
objects.  The  data  element  name  includes  the  name  of  the  reference  element  that  has  the 
appropriate  range  of  acceptable  values.  Note  that  it  is  the  structure  of  a  data  element  that  is 
standardized,  not  the  use  of  a  data  element.  Data  element  aliases  identify  data  elements  in 
use  in  specific  systems  and  locations,  and  they  are  used,  temporarily,  to  bridge  the  gap 
between  standard  elements  and  nonstandard  names  being  used  in  fielded  systems. 
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APPENDIX  G 

BACKGROUND,  OBJECTIVE,  AND 
ADDITIONAL  GUIDANCE 

(U)  This  IDA  Memorandum  Report  was  written  in  response  to  Task  Order  T-Jl- 
246  and  Amendment  No.  6.  Those  portions  of  the  task  order  that  pertain  to  the 
background  and  objectives  of  the  task,  and  the  additional  guidance  provided  therein  by  the 
sponsoring  office,  are  reprinted  here. 

2.  BACKGROUND : 

The  tactical  ADP  portion  of  the  NATO  Long  Term 
Defense  Program  (LTDP )  proposed  that  command  and  control 
systems  be  built  to  common  specifications.  The  Deputy 
SACEUR  initiated  a  study  to  determine  the  feasibility  of 
the  nations  in  the  Central  Region  commonly  developing  an 
Automated  Army  Tactical  Command  and  Control  Information 
System  (ATCCIS)  for  deployment  in  the  post-1995 
timeframe.  Commitments  for  supporting  this  effort  were 
obtained  from  US,  UK,  and  FRG  Army  Chiefs  of  Staff. 
These  nations  provided  information  on  their  operational 
doctrine,  procedures,  functions,  and  information 
exchange  requirements  for  their  maneuver  forces,  as  well 
as  their  operational  requirements  for  an  automated  CCIS 
and  information  on  the  ADP  systems  that  they  are 
currently  developing  to  support  their  maneuver  forces. 
This  information  was  used  in  the  initial  phase  of  the 
study  to  determine  the  extent  to  which  similarities  and 
differences  in  national  requirements  for  automated  CCISs 
would  indicate  that  a  commonly  developed  system  is 
potentially  feasible.  The  results  of  ths  initial  phase 
were  positive.  SHAPE  has  requested  that  their  nations 
complete  the  study  and  has  received  US,  UK  and  FRG  Army 
Chiefs  of  Staff  commitments. 
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3.  OBJECTIVE ; 

The  objective  of  this  phase  II  effort  of  the  study  is 
to  assist  SHAPE  in  defining  the  military  objectives  and 
basic  operational  requirements  for  a  common  ATCCIS  that 
achieves  interoperability  to  ADP  systems.  The 
capabilities  of  ADP  systems  are  to  be  compared  to  the 
concept  of  operations  of  each  of  the  nations  to 
determine  the  extent  to  which  such  a  common  ATCCIS  could 
accommodate  the  requirements  of  each  nation  and  to 
identify  issues  remaining  to  be  resolved  before  such  a 
system  could  be  employed  in  the  Central  Region  in  post- 
1995  time  period. 

4.  ADDITIONAL  GUIDANCE; 

The  FY  1988  task  includes: 

a.  Continue  tasks  to  support  the  establishment  of  the 
organizational  and  operational  concept,  operational 
requirements,  and  technical  concept  for  the  ATCCIS. 

b.  Continue  review  of  the  U.S.  operational  doctrine, 
procedures,  functions,  and  information  exchange 
requirements  for  the  maneuver  forces  and  operational 
requirements  for  automated  CCIS  and  the  ADP  systems 
currently  being  developed  with  a  view  towards  post-1995 
as  necessary  to  conduct  the  study.  This  specifically 
includes  efforts  underway  to  develop  and  support 
dispersed  command  posts . 
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DISTRIBUTION  LIST 


Office  of  the  Assistant  Secretary  of  Defense  (C3I) 
ATTN:  Mr.  V.  Russell 
The  Pentagon,  Room  3D  174 
Washington,  DC  20301 

Office  of  the  Assistant  Secretary  of  Defense  (C3I) 
ATTN:  LTCT.  Parrish 
The  Pentagon,  Room  3D  174 
Washington,  DC  20301 

HQDA  ODISC4 

ATTN:  SAIS-ADO  (LTC  R.  Farmer) 

The  Pentagon,  Room  1C670 
Washington,  DC  20301 

HQDA  ODISC4 

Interoperability  and  Standards  Office 
ATTN:  SAIS-ADO  (COL  R.  Potts) 

The  Pentagon,  Room  1C670 
Washington,  DC  20301 

HQDA  ODISC4 

ATTN:  SAIS-ADA  (Maj  M.  Napoliello) 

The  Pentagon,  Room  1C670 
Washington,  DC  20301 

Office  of  the  Joint  Chiefs  of  Staff 
ATTN:  J6U  (M.  Billings) 

The  Pentagon,  Room  1D770 
Washington,  DC  20301 

Office  of  the  Joint  Chiefs  of  Staff 
ATTN:  JMCEB  (Cdr  A.  Mitchell) 

The  Pentagon,  Room  1B707 
Washington,  DC  20301 

Director,  JTC3A  (C3A-ARM) 

ATTN:  C3-WA(ASD(C3RASC) 

Washington,  DC  20301-3160 
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• 

Director,  JTC3A  (C3A-AR) 

ATTN:  MAJ  Jakobowski 

Russell  Hall 

Fort  Monmouth,  NJ  07703-5513 

2 

• 

Director,  JTC3A  (C3A-AR) 

Technical  Standards  Office 

3 

ATTN:  C3A-ADW-S  (0.  Schultz,  Gary  Koener) 

DCA/JTC3A 

11440  INS-N 

Reston,  VA  22090-5006 

• 

Director,  Defense  Communications  Agency 

Defense  Communications  Engineering  Center  (DCEC) 

ATTN:  Code  R640  (S.  Lloyd) 

1860  Wiehle  Avenue 

Reston,  VA  22090-5500 

3 

• 

CINCUSAREUR 

6 

ATTN:  AEAIM-AA  (Maj  J.  Fleming) 

APO  New  York  09403 

• 

Chief,  Rationalization,  Standardization,  and  Interoperability 

U.S.  Army  Signal  Center 

Directorate  of  Combat  Development 

ATTN:  ATZH-CDQ 

Fort  Gordon,  GA  30905 

3 

• 

Commander,  CECOM 

PEO  Army  Command  and  Control  Systems 

ATTN:  AMSEL-ACCS  (R.  Giordano,  T.  Collins) 

Fort  Monmouth,  NJ  07703-5000 

10 

Commander,  CECOM 

PEO  Communications 

ATTN:  AMSEL-Comm 

Fort  Monmouth,  NJ  07703-5000 

2 

• 

Commander,  CECOM 

Avanced  Systems  Concepts  Organization 

ATTN:  AMSEL-RD-ASCO-RA  (E.  Tawil) 

Fort  Monmouth,  NJ  07703-5000 

2 

• 

Commander,  CECOM 

Information  Systems  Division 

Protocol  and  Standards  Team, 

ATTN:  AMSEL-ISD-SD  (J.  Savin,  J.  Onufer,  A.  Talerico) 
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Fort  Monmouth,  NJ  07703-5000 

• 
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Commander,  CECOM 
Systems  Division 
ATTN:  RD-C3-D  (J.  Plant) 

Fort  Monmouth,  NJ  07703-5000 

Commander,  CECOM 

ATTN:  SPIS-CC-TF  (LTC  G.  Banks,  S.  Levine) 

Fort  Monmouth,  NJ  07703-5000 

Commander,  CECOM 

ATTN:  SPIS-CC-OTDS  (Col  J.  Doyle,  J.  D'Oria) 

Fort  Monmouth,  NJ  07703-5000 

Commander,  U.S.  Army  CACDA 
ATTN:  ATZL-CAC-CR  (CPT  (P)  B.  Bray) 

Fort  Leavenworth,  KS  66027-5300 

Commander,  U.S.  Army  Information  Systems  Command  (USISC) 
Information  Systems  Software  Development  Center 
ATTN:  ASBF-SMS  (C.  Venditto) 

Fort  Huachuca,  AZ  85613-5450 

U.S.  Army  Development  and  Employment  Agency  (ADEA) 

ATTN:  Direction,  ATCCS  Experimental  Site 
Fort  Lewis,  WA  98433 

U.S.  Army  Development  and  Employment  Agency  (ADEA) 

ATTN:  UKSPO  (LTC  R.B.  Hawken) 

ATCCS  Experimental  Site 
Fort  Lewis,  WA  98433 

U.S.  Army  Development  and  Employment  Agency  (ADEA) 

ATTN:  MARLNO  (Maj  D.  Rape) 

ATCCS  Experimental  Site 
Fort  Lewis,  WA  98433 

Chief  of  Naval  Operations 

Director,  Naval  Communciations  Division 

ATTN:  OP-941C  (Maj  B.T.  Diekema) 

The  Pentagon,  Room  5A686 
Washington,  DC  20350 

Chief  of  Naval  Operations 
Tactical  C2  Systems  Branch 
ATTN:  OP-942G 
The  Pentagon,  Room  5E523 
Washington,  DC  20350 
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Chief  of  Naval  Operations 

Director,  Information  Management  Support  Division 

ATTN:  OP-945D  (P.  McKenna) 

The  Pentagon,  Room  5E573 
Washington,  DC  20350 

HQ  Department  of  the  Navy,  Information  Resources  Management 
ATTN:  Technology  Assessment  Division  (M.R.  Potter,  T.  Senator) 
The  Pentagon,  Room  4C434 
Washington,  DC  20350 

Commander,  Space  and  Naval  Warfare  Systems  Command 

(SPAWAR),  Warfare  Systems  Engineering 

ATTN:  Interoperability  Branch,  Code  3213  (M.  Zich,  P.  Darby) 

NC-1,  Room  11E47 

2511  Jefferson  Davis  Highway 

Arlington,  VA  22202 

Commander,  Space  and  Naval  Warfare  Systems  Command 

(SPAWAR),  Warfare  Systems  Engineering 

ATTN:  Interoperability  Branch,  Code  3213  (M.  Zich,  P.  Darby) 

NC-1,  Room  1  IS  10 

2511  Jefferson  Davis  Highway 

Arlington,  VA  22202 

Commander,  Naval  Data  Automation  Command 
ATTN:  Code  32  (D.  Vaughn) 

Building  166 
Washington  Navy  Yard 
Washington,  DC  20374-1662 

Director,  C4  Division 
U.S.  Marine  Corps 
Code  CCA  (Col  Aginbroad) 

Navy  Annex,  Room  3020 
Washington,  DC  20380 

Commander,  Marine  Corps  Research,  Development,  and 
Acquisition  Command  (MCRDAC) 

ATTN:  TACSIIP  (A.  Harris,  Capt  C.  Howes) 

Navy  Annex,  Room  3020 
Washington,  DC  20380 

Commander,  Marine  Corps  Tactical  Systems  Support  Activity 
(MCTSSA) 

ATTN:  Col  D.  Gardner,  J.  Steenwerth 
Camp  Pendleton,  CA  92055-5080 
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HQ  USAF,  Tactical  Command  and  Control  Division 

ATTN:  XOORC 

The  Pentagon,  Room  BF881 

Washington,  DC  20330 

HQ  USAF 

ATTN:  AF/SCTI  (Col  K.  Kubiak) 

The  Pentagon,  Room  5C1080 
Washington,  DC  20330 

HQ  Tactical  Air  Forces 
ATTN:  TAFIG/IISQ 
Langley,  VA 

National  Institute  for  Science  and  Technology 

ATTN:  ICST  (J.  Mulvennay,  R.  Martin,  D.  Jefferson,  C.  Royster) 

Technology  Building,  Room  B266 

Gaithersburg,  MD  20899 

Defense  Technical  Information  Center 
Cameron  Station 
Alexandria,  VA  22314 

Institute  for  Defense  Analyses 
1801  N.  Beauregard  Street 
Alexandria,  VA  22311-1772 

TOTAL:  203 
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AAP 

ACCIS 

ACE 

ACP 

ADSIA 

ADatP 

ADP 

AM 

AND  IP 

ANSI 

ASCE 

ASN 

ATCCIS 

ATP 

C2 

CCIS 

CCITT 

CIEG 

CEEL 

DAFTG 

DALIMS 

DMF 

DMRM 

DMS 

DP 

FORMETS 

GLOT 

ICSI 

IEC 

IER 


GLOSSARY 

Allied  Administrative  Publication  (MAS) 

Automated  Command  and  .Control  Information  System  (NATO) 
Allied  Command  Europe  (NATO) 

Allied  Communications  Publication  (NATO) 

Allied  Data  Systems  Interoperability  Agency 
Allied  Data  Publication 
Automatic  Data  Processing 
ACE  Manual 

American  National  Directory  for  Information  Processing 
American  National  Standards  Institute 
Association  Service  Control  Elements  (OSI) 

Abstract  Syntax  Notation  (OSI) 

Army  Tactical  Command  and  Control  Information  System  (SHAPE) 
Allied  Tactical  I*ublication 

Command  and  Control 

Command  and  Control  Information  System 

Comite  Consultatif  International  de  Telegraphique  et  Telephonique 

(International  Telegraph  and  Telephone  Consultative  Committee) 

Common  Information  Exchange  Glossary 
Common  Information  Exchange  Language 

Database  Architecture  Framework  Task  Group  (ANSI) 

NATO  Data  Link  Message  Standards 
Data  Management  Facility  (ATCCIS) 

Data  Management  Reference  Model  * 

Data  Management  Subsystem  (ACE  CCIS) 

Draft  Proposal  (ISO) 

NATO  Message  Text  Formatting  System 

Glossary  of  Operational  Terms 

International  Coding  System  Identifier  (ISO  DP  7826) 

International  Electrotechnical  Commission 
Information  Exchange  Requirement 
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IRDS 

ISO 

ISWG 

JTC 

LTDP 

M 

MAS 

MTF 

NACISA 

NACISC 

NACISO 

NCCIS 

NCIS 

NIAG 

NIMP 

NIPD 

NIST 

NISTIR 

OSI 

PW 

PWG 

Q 

sc 

SCF 

SG 

SHAPE 

SMF 

STANAG 

STC 

STRADIS 


TADIL 

TCIS 


Information  Resource  Dictionary  System 
International  Organization  for  Standardization 
Information  Systems  Working  Group  (NACISO) 

Joint  Technical  Committee 

Long-Term  Defense  Plan  (NATO) 

Modifier 

Military  Agency  for  Standardization  (NATO) 

Message  Text  Format 

NATO  Communications  and  Information  Systems  Agency 

NATO  Communications  and  Information  Systems  Committee 

NATO  Communications  and  Information  Systems  Organization 

NATO  Command  and  Control  Information  System 

NATO  Common  Interoperability  Standards 

NATO  Industrial  Advisory  Group 

NATO  Interoperability  Management  Plan 

NATO  Interoperability  Planning  Document 

U.S.  National  Institute  of  Science  and  Technology 

NBS  Interim  Report 

Open  Systems  Interconnection 

Prime  Word 

Permanent  Working  Group 
Qualifier 

Sub-committee  (ISO);  Study  Committee 
Service  Control  Facility  (ATCCIS) 

Sub-group 

Supreme  Headquarters  Allied  Powers  Europe  (NATO) 

System  Management  Facility  (ATCCIS) 

NATO  Standardization  Agreement 
SHAPE  Technical  Centre 

Structured  Analysis,  Design,  and  Implementation  of  Information 
Systems 

Tactical  Data  Link 

Technical  Common  Interface  Standards  (TSGCEE  SG9) 
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TF 

Transfer  Facility  (ATCCIS) 

TM 

Technical  Manual 

» 

TSGCEE 

Tri-Service  Group  for  Communications  Electronic  Equipment 

WG 

Working  Group 

WP 

Working  Paper  (ATCCIS) 
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